(NASA— CP— 10115) A NASA-WIDE N93-22601 

APPROACH TOWARD COST-EFFECTIVE, 

HIGH-QUALITY SOFTWARE THROUGH REUSE 

(NASA) 125 p Unci as 


NASA Conference Publication 10115 

A NASA-Wide Approach 
Toward Cost-Effective, 
High-Quality Software 
Through Reuse 

Edited by 
Charlotte O. Scheper 
Research Triangle Institute 
Triangle Park, North Carolina 

Kathryn A. Smith 
Langley Research Center 
Hampton, Virginia 


Proceedings of the Second NASA 
Workshop on Software Reuse held at 
Research Triangle Institute 
Research Triangle Park, North Carolina 
May 5-6, 1992 


r- 

o 

o 

vO 


ro 

O 


Resea 


JANUARY 1993 


NASA 

National Aeronautics and 
Space Administration 

Langley Research Center 

Hampton, Virginia 23681-0001 



Contents 


1 Introduction 1 

1.1 Mission and Goals ^ 

1.2 Customers and Sponsors ■ 3 

2 Technical Rationale 5 

2.1 Benefits ^ 

2.2 Problems and Barriers 5 

2.3 Technical Approach ' 

2.3.1 Process ^ 

2.3. 1.1 Business Process 9 

2. 3. 1.1.1 Business Analysis 9 

2. 3. 1.1. 2 Incentives for Reuse 9 

2.3.1. 1.3 Management Policy 9 

2. 3. 1.2 Engineering Process 10 

2. 3. 1.2.1 Domain Engineering 10 

2.3. 1.2.2 System Engineering 11 

2.3. 1.2.3 Software Engineering 11 

2.3. 1.3 Legal Issues 11 

2.3. 1.3.1 Acquisition Policy 11 

2.3.1. 3.2 Capitalization Policy . . . • • 12 

p. i 


2. 3. 1.3. 3 Liability 12 

2.3.2 Technology 12 

2.3.2. 1 Engineering Methods 12 

2.3.2. 1.1 Object-Oriented Methods 13 

2. 3.2.1. 2 Generic Assets . . . ... . 13 

2.3.2. 1.3 Megaprogramming 14 

2.3.2. 2 Libraries 14 

2.3.2.2.1 User Interfaces 15 

2. 3.2.2. 2 Asset Classification 15 

2. 3. 2. 2. 3 Asset Management 16 

2.3 2.2.4 Library Interoperability . . . 16 

2. 3.2. 3 Measurement 16 

2. 3. 2.3.1 Certification Metrics 16 

2. 3. 2.3.2 Experience Metrics 17 

2.3.3 Assets 17 

2.3.3. 1 Life-cycle Products 17 

2.3. 3. 2 Captured Knowledge 18 

2.4 State-of-the-Art 19 

2.4.1 Current Status of NASA Efforts 19 

2.4.2 Assessment of State-of-the-Art 24 

3 Proposed Actions 37 



References 


38 


Appendix A: Workshop Participants 39 

Appendix B: Viewgraphs Presented at Workshop 42 


• • • 
P. Ill 



List of Figures 


2.1 Current Status of NASA Efforts 25 

2.1 Current Status of NASA Efforts (Continued) 26 

2.1 Current Status of NASA Efforts (Continued) 27 


p. IV 



List of Tables 


1.1 NASA Headquarters Customers (C) and Sponsors (S) in Software Reuse 

Efforts 4 

2.1 The Software Reuse Problem Space 8 

2.2 Technical Contacts for NASA Reuse Tools 19 


p. v 






1. Introduction 


NASA Langley Research Center (NASA Langley) sponsored a workshop on Soft- 
ware Reuse Tools on May 5-6, 1992, at the Research Triangle Institute (RTI) in 
Research Triangle Park, North Carolina. The workshop was hosted by RTI and 
led by Kathryn Smith of NASA Langley. Participation was by invitation only and 
included representatives from four NASA centers (Langley, the Jet Propulsion Lab- 
oratory, Goddard, and Johnson), COSMIC, the Air Force’s Rome Laboratory, and 
DARPA’s STARS/ ASSET program. A complete list of the participants is included 
in Appendix A of this report. 

The primary purpose of this workshop was to exchange information on software reuse 
tool development, particularly with respect, to tool needs, requirements, and effec- 
tiveness. The objectives of this information exchange were to 1) identify critical 
issues and needs in software reuse and 2) identify opportunities for cooperative and 
collaborative research by addressing the following questions. 


• How is software reuse defined? 

• What are NASA’s requirements? 

• What will be the benefits? 

• What needs to be done? 

• How can results be quantified? 


The participants in the workshop presented the software reuse activities and tools 
being developed and used by their individual centers and programs. These programs 
address a range of reuse issues: the creation, management, and use of repositories 
(or libraries); library interoperability; domain analysis; and component certification. 
Viewgraphs from the presentations are included in Appendix B of this document. 

The participants of this workshop agreed that NASA is faced with increased con- 
struction and use of software at a time when software development costs are rising 
and budgetary resources are shrinking. This increased need is due in part to the 
exponential growth in the amount of data resulting from NASA missions that must 
be processed and analyzed as well as to the growth in software needs to conduct, con- 
trol, and manage the missions themselves. Producing software becomes more difficult 
and more costly as software becomes more complex, documentation becomes more 



intricate, and technology undergoes rapid change. The participants concluded that a 
concerted effort to promote and enable software reuse is required to accomplish cost- 
effective software development, under these conditions. This report summarizes the 
workshop findings and presents the group’s plan for defining the goals and objectives 
for NASA-wide coordination of software reuse activities. 


1.1. Mission and Goals 

The mission of the group’s proposed software reuse activities is to facilitate the con- 
struction and use of high-quality, cost-effective software. It proposes to accomplish 
this mision by creating a quality-conscious reuse environment at NASA that builds 
on the agency’s past achievements in software development to accomplish today’s 
missions. 

Reuse is a process by which components created by activities in one software develop- 
ment effort are used again, with or without modification, in other software develop- 
ment efforts. Components include artifacts from all aspects of software development. 
These artifacts can be requirements, specifications, designs, code modules varying 
from low-level subroutine modules to stand-alone modules to complete subsystems, 
interface requirements, revision histories, component- and system-level test cases, his- 
torical performance metrics of usage and failure rates, development standards, and 
risk information. Activities include the complete range of development and mainte- 
nance activities, such as requirements analysis, design, implementation, testing, field 
operations, and maintenance modifications. Process includes both the creation of 
components that are capable of being reused as well as the actual reuse of compo- 
nents. It encompasses identification, construction, verification, storage, retrieval, and 
modification of components. 


The group has four specific goals for its reuse activities: 


1. Enable NASA missions in the era of very limited resources. This goal 
specifically addresses supporting the smaller, low-cost missions. The proposed 
reuse effort will accomplish this goal by putting into place a mechanism to build 
software better, faster, and cheaper than can currently be done. 

2. Promote and improve quality in NASA software products and pro- 
cesses. Two aspects to accomplishing this goal are the application of TQM 
principles to foster a quality-conscious environment, and the development and 



use of the processes and metrics necessary to achieve a higher SEI (Software 
Engineering Institute) software capability rating. 

3 Preserve, package, and exploit NASA’s software legacy. This goal will 
be accomplished by establishing a reuse environment that allows components 
from existing systems to be reused, that applies lessons learned from one system 
development to another, and that promotes interoperability among new and 
existing systems. 

1. Foster a pervasive culture of software reuse within NASA. Such a cul- 
ture is an integral part of creating a successful reuse environment. This goal 
can be accomplished through education and coordination. In the area of educa- 
tion, this proposed effort will seek to improve awareness of software reuse and 
to educate current and future engineers and managers. In the area of coordina- 
tion, it will work to increase collaboration across NASA and to formalize and 
incorporate reuse into the NASA software life-cycle process. 


1.2. Customers and Sponsors 


Table 1.1 identifies Nasa Headquarters customers and sponsors having an existing or 
potential interest in software reuse efforts. 


Tal)l<* 1.1. NASA Headquarters Customers (C) and Sponsors (S) in Software 
Reuse Efforts 


HQ Code 

Contacts 

Areas 

RC 

(S) Lee Holcomb 

HPCC, CAS, ESS 

RJ 

(S) Kristin Hessenius 

Aero R&T 

RS 

(S) Sam Vernneri 

Space R&T 

SMI 

(C/S) Joseph Bredenkamp 

Data Management 

SZE 

(C) Guenter Reigler 

Astrophysics 

SE 


EOS 

SS 


Space Physics 

SL 


Planetary 

SB 


Life Sciences 

SN 


Microgravity 

cu 

(S) Frank Penaranda 

Technology Transfer 

QE 

(S/C) Don Sova 

Technical Standards 

QR 

(S/C) Alice Robinson 
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2. Technical Rationale 


2.1. Benefits 


Results from a market analysis conducted for the ASSET repository were discussed 
at the workshop. This analysis determined that the perceived benefits of reuse are, 
in order of priority, improved cost/productivity, reduced development time, increased 
quality, and increased competitiveness. The surveyed users thought that the reuse 
approach would provide an improved development environment where prototyping, 
development, modification, and porting could be accomplished efficiently and more 
successfully. They also felt that it would provide better communication among the 
staff involved in the development. These improvements would lead to the projected 
cost/productivity and development time gains. The users felt that the quality and 
reliability of the software would be improved, without increasing development costs, 
due to the increased testing and easier maintenance that reuse would provide. Finally, 
they felt that the ability to produce higher quality software at less cost would let them 
bring a better product to the market faster than their competitors. 

The findings of this market analysis agree with the general consensus that cost savings 
can be realized through increased software reuse. These cost savings result not only 
from the reuse of code, but also from the retention of software engineering knowledge 
and experience in a database that others can access. This allows improvement of the 
development process by building on past experience and lessons learned. In fact, it 
is now thought that the greatest benefits will probably be realized by reusing more 
abstract artifacts of software development than code modules, including artifacts from 
the process, design, and model levels [1]. 


2.2. Problems and Barriers 


Before software reuse can be a practical reality, several issues relating to quality, cost, 
and usability must be resolved [2,3,4], The goal of reusable software is to cut costs, 
but, depending on the application and system, this may not always be the case [5]. 
Practically, component retrieval costs should be less than component development 
costs. A previous NASA workshop [6] concluded that there was a need for economic 
models of reuse that could quantify the cost tradeoffs, identify the cost factors, and 
allow the calculation of how many times a component must be reused to justify the 


cost of creating and reusing it. 

The ASSET market analysis concluded that barriers to software reuse exist in the 
lack of mature processes, standards, and tools for reuse; company cultures and atti- 
tudes based on current software development processes; the front-end investment cost 
of designing reusable software; unresolved legal issues such as intellectual property 
rights, licensing and contractual issues, and product liability; and a lack of component 
suppliers, maintenance and support, and concern. 

The following additional items were identified as potential barriers to reuse by the 
participants of this workshop: 

• The need for systems with unprecedented requirements 

• Limited information access mechanisms 

9 The perception that building new software is faster than searching, identifying, 
retrieving, understanding, and modifying existing software objects 

• A lack of methods/ procedures for reuse 

• No common environment for reuse 

• A lack of management support 

• A lack of successful case studies 



2.3. Technical Approach 


The proposed effort to promote and enable software reuse throughout NASA requires 
a coordinated attack on a broad set of entrenched, interrelated problems. The problem 
space is described in Table 2.1. 

Within each of these problem areas, progress can be made by pursuing all or some of 
the following seven activities: 


1. Define solution approach 

2. Evaluate feasibility 

3. Build prototype/product 

4. Agree upon broad standards 
• r >. Train 

b. Distribute 

7. Commercialize enlist industry support 

A matrix in which the problem areas are listed down the side, and the solution activ- 
ities along the top, provides a framework for assessing progress towards widespread 
software reuse. In the following subsections, each problem area is briefly described. 
In the next section, the state-of-the-art at NASA is examined by filling in the matrix 
with activities currently being pursued by NASA centers. 


2.3.1. Process 


Achieving widespread software reuse is not simply a technological problem, nor is it 
simply a matter of creating and collecting a large number of reusable assets. A reuse- 
based approach to software engineering requires a change in the processes followed by 
all parties involved. This includes not only engineering processes, but also investment, 
acquisition, and management processes. Each of these areas presents obstacles to 
reuse which must be overcome. By addressing them in terms of the roles involved, 
the authority and interrelationships of these roles, and the procedures they would 
follow in a reuse-based development context, an Operations Concept of reuse can 



Table 2.1. The Software Reuse Problem Space 


1. Process 

l.i T 

Business Process 

l.i.i 

Market Analysis 

1.1.2 

Incentives for Reuse 

1.1.3 

Management Policy 

1.2 

Engineering Process 

1.2.1 

Domain Engineering 

1.2.2 

System Engineering 

1.2.3 

Software Engineering 

1.3 

Legal Issues 

1.3.1 

Acquisition Policy 

1.3.2 

Capitalization Policy 

1.3.3 

Liability 

2. 

Technology 

2.1 

Engineering Methods 

2.1.1 

Object-Oriented Methods 

2.1.2 

Generic Assets 

2.1.3 

Megaprograrnming 

2.2 

Libraries 

2.2.1 

User Interfaces 

2.2.2 

Asset Classification 

2.2.3 

Asset Management 

2.2.4 

Library Interoperability 

2.3 

Measurement 

2.3.1 

Certification Metrics 

2.3.2 

Experience Metrics 

3. 

Assets 

3.1 

Life-cycle Products 

3.1.1 

Requirements 

3.1.2 

Designs 

3.1.3 

Code 

3.1.4 

Test Procedures 

3.1.4 

User Guides 

3.1.4 

Other Life-cycle Products 

3.2 

Captured Knowledge 

3.2.1 

Reuse Guidance 

3.2.2 

Reuse Experience 

3.2.3 

Process Models 
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be developed that can serve as a statement of vision against which progress can be 
measured. 


2. 3. 1.1. Business Process 

This category refers to the set of problems concerning the financing, acquisition, and 
management of reusable software and of software developed by means of large-scale 
reuse. It includes such issues as rights retained on reusable assets, royalty structures 
for the use of such assets, and liability for defects in the assets. 


2. 3. 1.1.1. Business Analysis 

The economics of reuse are not straightforward. Models of the return on investment 
have been developed which show the extent of reuse necessary to justify an initial 
investment in developing reusable software. Market analysis is necessary in order to 
estimate whether the projected reuse is a reasonable expectation in a given domain. 


2.3.1. 1.2. Incentives for Reuse 

Current Government acquisition policies, as stated in the Federal Acquisition Reg- 
ulations (FAR), tend to discourage reuse. For example, if a company cannot retain 
the rights to reusable software incorporated in a Government system, then there is 
no incentive for the company to invest the extra resources that reusable software re- 
quires. Similarly, development of reusable software under a Government program is 
implicitly discouraged, since such development requires additional resources and can 
drive up the cost of a single system. 


2.3.1. 1.3. Management Policy 

Reuse-based software development requires a shift of management priorities away 
from “whatever it takes to make this project succeed” to a longer-term vision encom- 
passing many projects. A domain orientation, which sees the development of a single 
system as one instance in the development of many similar systems, is thus required 
not just by engineers but also by management. 



2. 3. 1.2. Engineering Process 


This category refers to the technical procedures followed by software engineers through- 
out the development life cycle. Experience has shown that large scale reuse is not 
achieved by simply making libraries of reusable components available to developers, 
with no corresponding changes in the processes the developers follow. The “not in- 
vented here” (NIH) syndrome and various other obstacles to reuse necessitate a new 
understanding of what it means to develop software. This new understanding is en- 
capsulated in the term Domain Engineering, which must now be added to the familiar 
concepts of system and software engineering. 


2. 3. 1.2.1. Domain Engineering 

A domain is a family of similar systems. It corresponds to a familiar application area 
or technical area, such as avionics systems, satellite systems, accounting systems, 
database systems, communications systems, etc. Domains can contain subdomains, 
which represent standard parts of a complex system (for example, the ground segment 
of a satellite system). 

Domain engineering is a discipline that stems from the fact that, within a given 
domain, the same techniques, design alternatives, tradeoffs, rules of thumb, testing 
approaches — and other aspects of the engineering process — are frequently encoun- 
tered again and again. Whether there is a formal “software reuse” program in place 
or not, the most effective engineers informally reuse the knowledge and techniques 
that they have built up through experience. Domain engineering seeks to systematize 
this process and make the legacy of built-up knowledge available to all members of a 

development team. 

Domain engineering is an approach to developing systems by exploiting similarities 
within a given domain. Individual systems in a domain are developed by instan- 
tiating a generic architecture, which describes the common structure of systems in 
the domain. A good generic architecture also identifies the ways in which individual 
systems can vary; ideally, it provides an easily used mechanism, such as parameter 
instantiation, for describing the unique aspects of a new system. Through the use of 
the generic architecture and its instantiation mechanism, the development of strictly 
new software is kept to a minimum. 

Domain engineering is intrinsically evolutionary: each new application yields expe- 
rience that is fed back into the domain model (which consists of the generic archi- 
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tecture as well as the techniques and supporting knowledge necessary for using the 
architecture). This feedback means that the domain model — which is a model of 
recommended engineering practice within the domain — continually changes as re- 
quirements become more and more complex, and as improved solution techniques are 

discovered. 


2.3. 1.2.2. System Engineering 

Decisions made during the system design process (for example, partitioning decisions 
and processor allocation decisions) can impact the feasibility of reuse during soft- 
ware development. Thus, the concepts of reuse and domain engineering need to be 
integrated into the systems engineering process as well. 


2.3.1. 2.3. Software Engineering 

Developers must be trained to view reuse not just as an ad hoc labor-saving technique, 
but as part of an overall engineering discipline that minimizes risk by building on past 
experience. Reuse must not be relegated to the coding phase of a project. It is equally 
(perhaps more) important in the earlier life-cycle phases, i.e., requirements analysis 
and design, and can be effectively applied in other activities such as test planning 
and test development as well. 


2. 3. 1.3. Legal Issues 

This category refers to a range of problems that arise when reuse is attempted be- 
tween organizations (e.g., Government and industry). Changes are required in the 
Government’s acquisition policies as well as in the laws governing rights to software 
in the commercial arena. 


2.3.1. 3.1. Acquisition Policy 

As already mentioned, the FAR tends to discourage reuse on the part of Government 
contractors. Provisions need to be made for the retention of rights to reusable software 
incorporated in a Government system. In addition, the way in which software is 
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maintained may need to change, as source code for proprietary components may not 
be made available to a maintenance contractor. 


2. 3.1. 3.2. Capitalization Policy 

Investment in the development of reusable assets would by encouraged by a modified 
accounting system, in which newly written software could be amortized over a longer 
period of time than its development period. This would to some extent mitigate the 
additional expense of developing software to be reusable. 


2.3. 1.3.3. Liability 

As software assets come to be treated more as commercial products, the question 
of liability for errors arises. The question is intrinsically complex because the con- 
text in which an asset is intended to be reused is typically not completely defined 
(formal specification is not yet widespread in the software industry). Certification is 
an approximate process. The question becomes even more complex when there are 
multiple layers of reuse, e.g., component A from organization A is reused in tool B 
from organization B, which is reused in system C for organization C. 


2.3.2. Technology 

The technological problems have been addressed more extensively, to date, than the 
process issues. A great deal of progress has been made in our understanding of 
how to develop assets that are reusable, and how to organize and present these for 
easy location and access by developers. Less progress has been made in the area 
of measurement, i.e., how do we assess the success of a reuse program? Neverthe- 
less, significant technical problems remain in all three areas of engineering methods, 
libraries, and measurement. 


2.3.2. 1. Engineering Methods 

Creating reusable assets is a technical challenge because software requirements con- 
tinually evolve. Designing for reuse requires the ability to predict how requirements 
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will change over time, and in what different contexts an asset will have to be reused. 
The basic software engineering goals of modularity and encapsulation improve the 
chances of reuse but do not by themselves solve the problem. In fact, none of the 
methods discussed below solves the problem, but they represent significant progress 
in our understanding of what makes software reusable. 


2.3.2. 1.1. Object-Oriented Methods 

Data encapsulation and information hiding are basic techniques that aid in the defini- 
tion of components that are loosely coupled to their environment (and can therefore 
be reused in other environments). Decomposing software in terms of “objects,” which 
represent the entities or important “things” in a given domain, has turned out to be 
a systematic way of achieving data encapsulation and information hiding. This is 
known as object-based software development. Object-oriented development goes one 
step further by organizing objects into classes and subclasses. Members of a subclass 
inherit attributes and capabilities from the parent classes. Inheritance has been ad- 
vocated as a means of achieving reuse: by having an object inherit functions from 
a parent class, a developer does not have to re-implement them in the subclasses. 
However, systematic use of inheritance has also led to difficulties in reuse and main- 
tenance, which have been documented in the object-oriented programming literature 
(e.g., the proceedings of the Object Oriented Programming, Languages, Systems, and 
Applications — OOPSLA — Conferences). The difficulties stem primarily from the 
dependencies of a subclass on its parent classes. These dependencies work against 
the encapsulation (localization) of information that are a hallmark of good software 
engineering. 

Organizing objects into classes and subclasses can be a useful tool in understanding 
a problem domain during the analysis and design phases, even if inheritance is not 
implemented in the programming language used. Overall, there is a consensus in the 
software engineering community that object-orientation supports the development of 
reusable software. Unfortunately, there has been very little empirical measurement 
performed to test this belief. 


2. 3. 2. 1.2. Generic Assets 

Languages such as Ada (and now C++) allow for the definition of components that 
are generic, in that they are parameterized to allow their use in different contexts. 
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For example, a generic list package may be used to manage lists of different types of 
objects: the generic package is instantiated according to the particular object type 
to be supported in a given application. 

Recently, the notion of a generic asset has been extended to encompass more than 
code components. Software engineers now speak of generic architectures for certain 
types of systems (this is the thrust of a major DARPA program - Domain Specific 
Software Architectures). In the context of domain engineering (see Section 2.3. 1.2.1), 
we can even speak of generic requirements specifications. 

Class hierarchies and generic assets are two methods of building in variability, so as 
to increase the chances of an asset being reused. In a class hierarchy, variation is 
accommodated by the range of subclasses of a given parent class (e.g., the varieties 
of a window in a windowing system). In a generic asset, variability is accommodated 
by means of parameters that must be instantiated in order to use the asset. 


2.3. 2. 1.3. Megaprogramming 

Megaprogramming refers to the idea of building software systems out of large building 
blocks, each of which represents a rich capability in its own right. The consensus in 
the software engineering community seems to be that this can be achieved in domain- 
specific contexts, where the typical architecture and building blocks of a system are 
well understood. Megaprogramming is, for this reason, very closely related to domain 
engineering. 

In domains where there is a great deal of commonality from one system to another, 
the synthesis of the building blocks into new systems can often be described in terms 
of a very high-level language (VHLL); for example, architecture diagrams that re- 
fer to well-known subsystem implementations. Automated code generation plays an 
increasingly important and feasible role in this context to create the code that ties 
together the specified building blocks. 


2. 3.2. 2. Libraries 

Most of the research and development in software reuse has concentrated on the 
development of library systems. There are numerous issues remaining to be resolved 
concerning the best way to present information to the user, the most effective ways 
of organizing a library to facilitate finding desired assets, and the ability of multiple 
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libraries to interoperate in a seamless fashion despite differences in their internal 
storage procedures and user interfaces. 


2. 3. 2. 2.1. User Interfaces 

The overall problem here is to prevent a user from being overwhelmed by massive 
amounts of information while providing access to the assets that will meet his/her 
current requirements. The advent of graphics/windowing systems and of hyper- 
text /hypermedia systems has opened many new possibilities for presenting informa- 
tion to the user. In addition to query-driven database searches, some systems now use 
hypertext techniques that allow users to browse or navigate through the contents of 
a library, following reference or similarity links from one asset to another. Graphical 
interfaces can show “neighborhoods” of closely related assets, allowing the user to 
grasp the overall content of the library in a visual manner. 


2.3.2. 2.2. Asset Classification 

This problem bears directly on the ease with which users can locate assets meeting 
their requirements. Assets may be classified hierarchically, as in a tree structure, or by 
means of facets, which are independent attributes of an asset (e.g., function, author, 
programming language, etc.). Both overall methods present problems. Hierarchical 
schemes have been used in object-oriented programming systems such as Smalltalk, 
and have frequently proven difficult to use when the conceptual scheme assumed by 
the creator of the library is markedly different from that of the user. Faceted systems 
are frequently limited to describing superficial characteristics of an asset; for example, 
the function of a component may be described in a manner that leaves may questions 
about the operation of the component unanswered. 

In addition to problems with both methods of classification, determining the specific 
classification of an asset is inherently problematic. The name that one person uses to 
describe a function may be different from the name used by someone else. Support 
for synonyms and similarity is therefore desirable. 
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2.3.2. 2.3. Asset Management 


Software evolves, and not all reuse will be verbatim reuse. There will be circumstances 
in which modified assets are submitted to a library for inclusion as a variant to the 
original on which it is based. In addition, if problems with reuse are reported, it 
may be necessary to maintain software stored in a reuse library. These and other 
circumstances create a problem of managing the assets in a library. Procedures and 
supporting technology are needed for configuration control, access control, and similar 
asset management tasks. 


2. 3. 2. 2.4. Library Interoperability 

Widespread sharing of information among software engineers will require the ability 
of libraries to interoperate, so that requests at one library system can be satisfied by 
retrieving assets from another, perhaps geographically remote, system. The Reuse 
Library Interoperability Group (RIG) is currently addressing this problem. 


2. 3. 2. 3. Measurement 

This area has received the least attention of all the technological aspects of reuse, 
and yet it is crucial to achieving any kind of objective success. 


2.3.2. 3.1. Certification Metrics 

Various schemes have been proposed for annotating reusable assets with a certifica- 
tion measure — a description of the confidence the library management has in the 
correctness and quality of the asset. Because quality is not a precisely defined con- 
cept in software (it has different meanings on different projects), and because in the 
absence of formal specifications even correctness is not precisely defined, certification 
must be viewed as an approximate indicator rather than an absolute seal of approval. 
Methods for certifying reusable assets will evolve as testing theory, use of formal 
methods, and approaches to quality assurance evolve. 
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2.3.2. 3.2. Experience Metrics 


This category refers to the collection of measurements concerning the practice of reuse. 
These measurements may include how much software from a library is being reused, 
what percentage of new systems consists of reused code, how many successful vs. 
unsuccessful searches there have been in a library system over a given period of time, 
how many errors have been encountered in reused assets, how many modifications 
have been necessary in reusing an asset, what kinds and frequencies of problems have 
been encountered in reusing various assets, etc. 

Information gathered from such measurements can be used to refine the organization 
of a library, improve the procedures for using the library, improve other aspects of 
the software development process, filter out unneeded or substandard assets from 
a library, and in many other ways contribute to an ongoing process improvement 
program. 


2.3.3. Assets 

The development of a sizable store of reusable assets is, obviously, key to a successful 
reuse program. There are two main points to be made: 1) we should be thinking of 

reusing life-cycle products in general, not just code, and 2) we can (and must) reuse 
knowledge that has accrued over the years of developing systems in a domain. 


2. 3. 3.1. Life-cycle Products 

Many products created over the course of the software development life-cycle can 
be reused effectively in future systems. Many researchers in the field have come to 
the conclusion that reusing code without reusing requirements, specifications, and 
designs will never lead to more than ad hoc reuse. It is the requirements and design 
that establish the context for code components — for example, the interfaces — 
a context that is either consistent or inconsistent with the assumptions of existing 
code components. Thus, it is in the requirements analysis and design phases that 
key decisions affecting the potential for reuse are made. To the extent that these 
decisions are consistent with those made in the past (i.e., requirements and designs 
are reused), the chances of successfully reusing code are increased. 

In addition, there are the obvious economic benefits to be gained if a design specifi- 



cation, for example, can be created by means of a few modifications to an existing 
document. This is also a means of reducing risk on a project, since the number of 
decisions without precedent is reduced. 

2. 3. 3. 2. Captured Knowledge 

It is sound engineering discipline to build on knowledge accumulated through prior 
efforts, but relatively little attention has been paid to integrating this process into a 
reuse framework. The advantage of doing so is that knowledge can be shared rather 
than remaining in the mind of a single developer. A reuse program should therefore 
look at ways of packaging previously accrued engineering knowledge so as to make it 
available to the developers of new systems. 

The 1990 report of the Computer Sciences and Technology Board (CSTB) of the 
National Research Council strongly recommended the use of handbooks in specific 
disciplines as a means of packaging and transferring this kind of knowledge (Commu- 
nications of the ACM, March 1990). Such “handbooks” could in fact be on-line and 
made available as part of a reuse environment, providing guidance on how to reuse 
various assets, information about past experience in reusing specific assets (lessons 
learned), and criteria for choosing reusable assets. 

In addition, alternative process models, suitable for projects with different character- 
istics (e.g., size, criticality, performance requirements, etc.), could be stored and made 
available as part of this on-line database of knowledge. This knowledge would con- 
stantly evolve as a function of the experience metrics collected (see Section 2. 3.2. 3. 2). 
In the long run, the reuse of packaged knowledge of this sort can have a great impact 
on software quality and productivity because they directly address the risk factors 
associated with software development. 
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2.4. State-of-the-Art 


2.4.1. Current Status of NASA Efforts 

The workshop identified current reuse activities at four NASA centers: Langley Re- 
search Center, the Jet Propulsion Laboratory, Goddard Space Flight Center, and 
Johnson Space Center. The tools resulting from these activities are described in the 
following sections, and the technical points of contact are summarized in Table 2.2. 


Table 2.2. Technical Contacts for NASA Reuse Tools 


Technical Contact 

NASA Center 

Tools/ Programs 

Kathryn Smith 

LaRC 

Eli (InQuisiX) 

Randy VanValkenburg 

LaRC 

SEAL 

Ed Ng 

JPL 

HyLite 

Walt Truszkowski 

GSFC 

LEARN-92, KBSEE 

Mike Bracken 

GSFC 

KAPTUR 

Charles Pitman 

JSC 

RBSE, REAP, SimTool, PCS/ESL 


NASA Langley Research Center 

The Eli Software Synthesis System is an automated set of cooperating reuse tools 
that NASA Langley has been sponsoring. It is in its third phase of development, dur- 
ing which it is being commercialized as InQuisiX. The component tools are library 
facilities to classify, store, and retrieve reusable components; design synthesis; com- 
ponent checkout; file checkout; and Ada component metrics. Eli has been designed to 
be tailorable to specific users needs. It supports user-defined component classes and 
classifications and many types of attributes. The goal of this system is to automate 
the development and use of reusable components to make software reuse easier to 
accomplish. 

Eli is an operational product, running under XI 1 on a Sun4. It has a window and 
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menu-based user interface. It manages code, design, test case, and documentation 
components and performs the complete set of library functions. Additionally, it pro- 
vides facilities for integrating library components into new systems under develop- 
ment. 

The Software Engineering a nd Ada Laboratory (SEAL) at NASA Langley is involved 
in a number of efforts that will facilitate the implementation of reuse in the software 
development process. A domain analysis is underway that will identify the poten- 
tial for reuse for the domain of interest to the SEAL. The SEAL is cooperating 
with the hardware and systems engineering branches at Langley to document a sys- 
tems engineering approach that includes participation of software engineers from the 
earliest stage of development and that will advocate the development of standards 
for hardware, limiting the options software has to address. An object-based design 
methodology has been defined in the SEAL and many of the code modules actually 
developed are in the form of reusable, generic Ada packages. Finally, the SEAL is 
developing guidebooks for developing reusable Ada components/ systems and for a 
tailorable software engineering process. 

The Jet Propulsion Laboratory 

HyLite is an R&D activity of JPL that is producing a tool to facilitate the con- 
struction of electronic libraries for software components, hardware parts or designs, 
scientific databases, bibliographies, etc. HyLite evolved from a task formerly entitled 
the Encyclopedia of Software Components (ESC) and its major area of applicability 
has thus far been software resue. HyLite has a graphical user interface (GUI) to its set 
of library functions. These functions include inserting new components and property 
knowledge, browsing and searching databases, and retrieving software from selected 
networks. It also contains a library of math software and a library of data structures 
and algorithms. 

HyLite has employed advanced technology in developing its component functions. 
These technologies include object-oriented databases, semantic networks for classi- 
fication, and automatic GUI generation. The effort is currently addressing the use 
of A I technologies for intelligent retrieval based on learning from experience, user 
models, the correction and/or completion of retrieval statements, and suggestions for 
alternative retrievals. 

A prototype for beta testing exists for the color Macintosh. The prototype uses 
SuperCard, Macintosh Allegro Common Lisp, Pixel/Paint Professional, Canvas 2.0, 
and Think C to implement the system’s functions. This prototype is currently being 
ported to UNIX workstations running under XWindows and will be upgraded to 
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include the AI technologies, a history mechanism, and more complete Hypertext 
capabilities. Additional efforts are underway to adapt HyLite as a graphical front- 
end for a national software exchange experiment, to adapt it as an intelligent front-end 
to NAIF (a library of software tools and datasets for space flight navigation systems), 
and to connect to NetLib. Initial preparations are being made for commercialization. 

Goddard Space Flight Center 

LEARN-92 (Learning Enhance d Automation of Reuse Engineering) is an experimen- 
tal project that is using conceptual clustering techniques from artificial intelligence 
to automatically develop a classification scheme for code components. This capabil- 
ity would support the domain engineer, who must create a classification scheme for 
components as part of the domain model. A prototype version of the tool is planned 
to be completed by the end of September 1992. 

LEARN-92 is intended to provide the software engineer with a classification of compo- 
nents based on their role in the problem space (i.e., what problem they solve), rather 
than the solution space (how they are implemented.) The inheritance hierarchy of an 
object-oriented programming system, such as C++, provides a solution-space organi- 
zation; this is often not very helpful to programmers who are searching for a reusable 
component to perform a specific function. 

LEARN-92 will provide an automated mechanism for hierarchical classification of 
code components, based on faceted descriptions of these components. A unique aspect 
of the faceted descriptions is that the facet space is extendible “on the fly" by the 
user who is placing a component into the system. The user is encouraged, but not 
required, to use existing facets in describing a new component. The focus in this 
effort is on code components, but the classification mechanisms being implemented 
in LEARN-92 could work for other forms of assets as well. 

KAPTUR (Knowle dge Acquisition for Preservation of Trade-offs and Underlying 
Rationales) is a tool under development for preserving and building on NASA’s en- 
gineering legacy. It captures the engineering decisions/rationales that went into the 
development of software assets and provides an easy-to-use environment for accessing 
that knowledge. The functionality implemented by KAPTUR includes entering new 
architectures, recording rationales, placing rationales within the context of an over- 
all domain model, browsing alternatives, understanding decisions, and selecting for 
reuse. 

KAPTUR supports an approach to domain engineering in which assets are organized 
in terms of their distinctive features , which represent key engineering decisions, and 
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which are justified by rationales. The approach is also distinguished by the fact 
that it is case-based , i.e., actual legacy products are included in the database, not 
just generic models for future use. KAPTUR’s approach to asset classification uses 
a typing structure including both domain-independent and domain-dependent asset 
types. Within a type, assets are classified on the basis of their features. The KAPTUR 
concept of feature is broader than that found in the Software Engineering Institute’s 
Feature-Oriented Domain Analysis (FODA) method. KAPTUR employs a novel user 
interface approach which is based more on direct display and manipulation of the 
database rather than queries. A hierarchical map of alternatives and a stack of pages 
describing them are presented to the user in a window and menu-based format. 

KAPTUR currently runs on a Sun SPARCS Station. Version 2.0 has been released, 
following versions 1.0 and two earlier prototypes. The system is currently being 
distributed to interested/potential users, and a training course on KAPTUR and 
Domain Analysis is being developed. The developers of KAPTUR maintain that the 
continuous feedback loop this type of system provides between the supplier of reusable 
components and the user of those components is the key to successful reuse. 

The KBSEE (Knowledge-Based Software Engineering Environment) is a prototype en- 
vironment to support the production of new systems by configuring generic assets 
stored in a domain model. It incorporates the Evolutionary Domain Life-Cycle 
(FDLC) model in which new systems are used to update the domain model to make 
it more responsive to future requirements. 

The KBSEE makes reuse the central activity of the software engineering process. De- 
velopment is seen as a process of identifying the required features of a new system, 
retrieving the assets possessing those features from the generic domain model, check- 
ing the mutual consistency of the assets, and configuring them into the new system. 
Specification of the required features is done by the developer; all the other steps are 
performed by the KBSEE. 

The domain model, as stored by the KBSEE, consists of a hierarchy of generic assets, 
each of which possesses certain features that make it suitable or unsuitable for a 
given application. The generic assets are created through the process of Domain 
Analysis, which abstracts the functionality found in existing and planned systems in 
the domain. 

Assets are organized into whole-part and class-subclass hierarchies. In addition, assets 
possess features (similar to the notion of feature in the Software Engineering Insti- 
tute’s FODA method), which are used to determine which assets should be retrieved 
to meet the requirements of a new system. Features are described as mandatory (must 
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be present in any system), variant (one of several variants must be present in any 
system), or optional (may or may not be present). 

A prototype KBSEE has been developed, and its feasibility is now being tested in the 
Payload Operations Control Center domain. The KBSEE effort has focused to date 
on the storage of generic requirements specifications and the automated configuration 
of requirements specifications for new systems based on the generic versions. This 
supports a development process that consists of configuring assets each of which can 
represent a complex capability in its own right. This highly automated concept of 
software development supported by the KBSEE makes it suitable for megaprogram- 
ming. 

Johnson Space Center 

The NASA Repository - Based Software Engineering Program (RBSE) directed by 
NASA Johnson Space Center has operated a prototype public-domain software reuse 
library (AdaNET) since 1989. Updates to the AdaNET architecture, including high- 
performance hardware and an open-systems-based library management system are 
reversing a trend to degraded responsiveness and capability. The RBSE is commit- 
ted to making reuse part of the mainstream of software development practices and 
is working to achieve this by delivering and supporting a robust set of products sup- 
porting research to fill critical technology gaps, and adapting to changing customer 
requirements. Through the Reuse Interoperability Group, RBSE is involved in de- 
veloping standards for interoperability among government-funded reuse libraries, and 
sees interoperability as key to expanding the base of library suppliers and customers. 

In addition to RBSE, NASA’s Johnson Space Center supports several activities that 
are related to software reuse. The Re-Engineering Application/Proje ct (REAP) is 
developing an integrated reengineering environment, including methods and tools. It 
captures all code and as much as possible of other software life cycle products in 
an electronic repository and provides analysis support for abstracting, grouping, and 
structuring the information. 

SimTool is also supporting the domain engineering process through the construction 
of simulations of new applications based on a library of models from the domain. 
Using SimTool’s library of executive software components, application interfaces, and 
math models, the user builds an application specification. This specification identifies 
which components are to be integrated and how they relate to each other and the 

simulation. 

The Parts Composition System/Engineering Script Language (PCS/ESL) provides re- 
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usable, domain-specific software parts, catalogs of parts, and libraries. The software 
parts consist of primitive modules and drivers/ graphs. This tool lets the developer 
retrieve parts from the library and recombine or modify them into new, executable 
applications. The modules and applications are represented in the library as graphs. 
The ESL is a graphical language for composing complete applications from software 
parts, and as such is one approach to megaprogramming. A prototype of this system 
has been built and is being tested. 


2.4.2. Assessment of State-of-the-Art 

A problem area/solution activities matrix based on the framework described in Sec- 
tion 2.3 was created to determine and assess the current status of reuse activities 
at the NASA centers. The participants at this workshop filled in the matrix with 
respect to the reuse activities and tools being pursued by their centers^ These indi- 
vidual results were then compiled into the matrix in Figure 2.1 using the following 
key to identify the individual tools: 

Tool Number Jpol Name 


1 

Eli (InQuisiX) 

2 

HyLite 

3 

SEAL 

4 

RBSE 

51 

LEARN- 92 

52 

KAPTUR 

53 

KBSEE 

6 

RBSE, REAP, SimTool, PCS/ESL 


Notes related to individual column entires are included after the table. 

This matrix provides a snapshot of existing NASA reuse activities in a framework that 
denotes their status with respect to the issues that this workshop identified as crucial 
to the successful development of a NASA-wide reuse environment. This snapshot 
clearly illustrates where NASA is now and provides a basis for determining where 
future efforts should be directed in resolving these issues. 
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PROCESS PORTION OF MATRIX 



Figure 2.1. Current Status of NASA Efforts 


















































TECHNOLOGY PORTION OF MATRIX 



Figure 2.1. Current Status of NASA Efforts (Continued) 
























































ASSETS PORTION OF MATRIX 



Figure 2.1. Current Status of NASA Efforts (Continued) 



































































PROCESS NOTES 


Tool 3: SEAL 


Cells 6G,J - The domain analysis of 13G should answer the market analysis question: 
does the potential for reuse in our domain justify the cost of reuse efforts? See 

13J. 

Cell 101 - SEAL management is committed to the “domain orientation, and we 
are seeking to educate other areas of management via classes and informal 
interactions. 

Cells 13G,J - A “Domain Analysis” of the SEAL software application domain(s) 
is being conducted to reveal the commonalities between development projects. 
This is a deliverable under a task being conducted by the SEAL for the Code 
QE Software Engineering Program. 

Cells 15E,H - The SEAL is cooperating with LaRC hardware and systems engi- 
neering branches to document a systems engineering approach that includes 
participation of software engineers in the earliest stages. The SEAL advocates 
limiting hardware choices, such as buses and microprocessors, to selections from 
a small set of agreed upon standards. This will further promote reuse of software 
components. 

Cells 17G,H,1,J - These are addressed in Asset cells 23G,H,I,J. The referenced guide- 
books will also cover the management and assurance processes. 


Tool 4: RB5E. 


Cell 8E - RBSE participates in the Reuse Acquisition Action Team, a group which 
is focused on management/acquisition issues of reuse. It is sponsored by the 
ACM/SIGAda Reuse Working Group. The group has strong support from 
DoD’s Executive Reuse Steering Committee and acquisition/policy officers from 
Army, Navy and Air Force. 

Cell 10E - RAAT (See 8E) 
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Cell 13E - RBSE is active in developing the Software Engineering Institute’s “Design 
for Reuse Handbook.” RBSE sponsored a workshop earlier this year at the 
University of Houston, Clear Lake. 

Cells 13-24J - AdaNET provides information about a range of reuse- related tech- 
nical and non-technical issues. Information on these and other topics may be 
available. 

Cell 20 E - RAAT (See 8E) 


Tool 51: LEARN-.32 


Cell 13 - LEARN-92 is an experimental project that is using conceptual clustering 
techniques from artificial intelligence to automatically develop a classification 
scheme for code components. This capability would support the domain en- 
gineer, who must create a classification scheme for components as part of the 
domain model. A prototype version of the tool is planned to be completed by 
the end of September 1992. 

Cell 17 - LEARN-92 is intended to provide the software engineer with a classifica- 
tion of components based on their role in the problem space (i.e., what problem 
they solve rather than the solution space (how they are implemented). The 
inheritance hierarchy of an object-oriented programming system, such as C++, 
provides a solution-space organization: this is often not very helpful to pro- 
grammers who are searching for a reusable component to perform a specific 
function. 

Tool 52: KAPTUR 


Cell 13 - KAPTUR supports an approach to domain engineering in which assets 
are organized in terms of their distinctive features , which represent key engi- 
neering decisions and which are justified by rationales. The approach is also 
distinguished by the fact that it is case-based , i.e., actual legacy products are 
included in the database, not just generic models for future use. 

KAPTUR 2.0 has been released, following version 1 .0 and two earlier prototypes. 
The system is currently being distributed to interested/potential users, and a 
training course on KAPTUR and Domain Analysis is being developed. 


p. 29 


Tool 53; K BSEE 


Cell 13 - The KBSEE is a prototype environment intended to support domain 
engineering; in particular, the production of new systems by configuring generic 
assets stored in a domain model. It is based on an evolutionary concept of 
domain engineering, in which new systems are used to update the domain model 
to make it more responsive to future requirements. A prototype KBSEE has 
been developed, and its feasibility is now being tested in the Payload Operations 
Control Center domain. 

Cell 17 - The KBSEE makes reuse the central activity of the software engineering 
process. Development is seen as a process of identifying the required features of 
a new system, retrieving the assets possessing those features from the generic 
domain model, checking the mutual consistency of the assets, and configuring 
them into the new system. Specification of the required features is done by the 
developer; all the other steps are performed by the KBSEE. 


Tool 6: Johnson Space Center Tools 


Cell 13 - Domain Engineering - Two projects, ESL and SimTool, are investigating 
various aspects of domain architectures and reuse, and are discovering implica- 
tions for the domain engineering process. 

Cell 17 - Software Engineering - Three projects, REAP, FPP, and ESL, are address- 
ing aspects of the software engineering process: 

(i) REAP (Re-engineering Application Project) is developing an integrated 
re-engineering environment, including methods and tools. 

(ii) FPP (Framework Programmable Platform) is focusing on the descrip- 
tion, management, and control of the software development process within an 
integrated life-cycle environment. 

(iii) ESL (Engineering Script Language) is a graphical language for compos- 
ing complete applications from software parts in a reusable library, and it is 
investigating a process for composing applications. 
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TECHNOLOGY NOTES 


Tool 1: Eli/InQuisiX 


Cells 13, 15, 17, 19;E-G - The Eli (InQuisiX (TM) Software Synthesis System in- 
cludes a graphical user interface and a library system. The library system sup- 
ports classification, retrieval and management of components. InQuisiX was 
developed under an SBIR; the company is preparing a commercial product. 

Cells 2‘2E,F - Identify a set of measurable reuse attributes for object-oriented systems 
and design a prototype tool to take these measurements. 


Tool 2: HyLite 

Cells 6F,G - Applying object-oriented DBMS methods for software reuse. 
Cells 13F,G - Applying hypermedia technology. 

Cells 15-19 F,G - Applying A I techniques for navigation in databases. 
Tool 3: SEAL 


Cells 6E-K - An object-based design methodology has been defined in the SEAL. 
Applied to a flight software project and published in several papers. The guide- 
books of Asset Cell 23G will define a suite of object-oriented methods to be 
used in the SEAL for analysis, design, and implementation. Training in these 
chosen methods will be given at LaRC. The SEAL provides feedback to software 
development tool vendors about features that are desirable. 

Cells 8G-J - Many of the code modules developed in the SEAL are in the form of 
reusable, generic, Ada packages. Ada has been adopted as the development 
language for the SEAL. SEAL guidebooks for developing reusable Ada com- 
ponents/systems (See Asset 19G) will be the basis of reuse training for new 
personnel. The generic Ada packages will be made widely available via asset 
repositories such as COSMIC and AdaNET. 
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Cells 10F G I - The domain analysis of Process 13G will identify the feasibility of 
megaprogramming in our domain by determining the common building blocks 
in our systems. New systems will be megaprogrammed from existing reusable 
assets, which have been designed with standard protocols, methodologies, and 

hardware in mind. 

Cells 15EG - The domain analysis of Process 13G will identify attributes and 
facets’ of our domains that will enable us to develop classification schema for 
our reusable assets. These schema will be initially implemented using the 
ELI/ARCS reuse tool system developed under a LaRC SBIR. 

Cell 24E - The SEAL will be identifying metrics to measure all aspects of the software 
development process, including reuse activities. These will be formalized in the 
guidebooks of Asset 23G. 


Tool 4: RBSE 


Cells 6-24J - AdaNET provides information about a range of reuse-related tech- 
nical and non-technical issues. Information on these and other topics may be 

available. 

Cell 13E - Trade study 
Cell 13F - Feasibility study 

Cell 13G - RBSE’s operational reuse library component, AdaNET, has developed 
and operated a prototype reuse library. The system is to be upgraded this fall. 
System will include X-windows, MAC, and PC-based GUI. 

Cell 15E - RBSE has sponsored work by Dr. David Eichmann and others to develop 
lattice-based classification schemes of reuse libraries. 

Cell 15G - AdaNET (see 13G). 

Cell 17G - See AdaNET (see 13G). 

Cell 19E - RBSE provides active support and leadership to the Reuse Library In- 
teroperability Group, an organization developing consensus- based standards for 
interoperability among government-funded reuse libraries. 
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Cell 19F - RBSE is holding discussions with another reuse library to prototype 
interchange of assets. 

Cell 19H - RIG (see 19E). 

Cell 22E - RBSE has conducted trade studies on certification metrics. 

Cell 22F - RBSE is evaluating the feasibility of certification metrics with off-the-shelf 
tools. 

Cell 24 E - RBSE co-chairs the RIG technical subcommittee on metrics. 

Tool 51: LEARN-92 

Cell 15 - LEARN-92 will provide an automated mechanism for hierarchical classifi- 
cation of code components, based on faceted descriptions of these components. 
A unique aspect of the faceted descriptions is that the facet space is extendible 
“on the fly” by the user who is placing a component into the system. The 
user is encouraged, but not required, to use existing facets in describing a new 
component. 


Tool 52: KAPTUR 

Cell 13 - KAPTUR employs a novel user interface approach which is based more on 
direct display and manipulation of the database rather than queries. 

Cell 15 - KAPTUR’s approach to asset classification uses a typing structure includ- 
ing both domain-independent and domain-dependent asset types. Within a 
type, assets are classified on the basis of their features. The KAPTUR concept 
of feature is broader than that found in the Software Engineering Institute’s 
Feature- Oriented Domain Analysis (FODA) method. 


Tool 53: KBSEE 

Cell 8 - The domain model, as stored by the KBSEE, consists of a hierarchy of 
generic assets, each of which possesses certain features that make it suitable or 
unsuitable for a given application. The generic assets are created through the 
process of Domain Analysis, which abstracts the functionality found in existing 
and planned systems in the domain. 
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Cell 10 - The highly automated concept of software development supported by the 
KBSEE makes it suitable for megaprogramming. The development process con- 
sists of configuring assets each of which can each represent a complex capability 
in its own right. 

Cell 15 - Assets are organized into whole- part and class/subclass hierarchies. In 
addition, assets possess features (similar to the notion of feature in the Software 
Engineering Institute’s FODA method), which are used to determine which 
assets should be retrieved to meet the requirements of a new system. Features 
are described as mandatory (must be present in any system), variant (one of 
several variants must be present in any system), or optional (may or may not 
be present). 

Tool 6: Johnson Space Center Tools 


Cell 6 - Object-oriented methods: one project, re-engineering the Mission Opera- 
tions Computer to an object-oriented design, is evaluating the feasibility of us- 
ing object-oriented technology in a previously assembly-language, mega-system 
domain. 

Cell 10 - Megaprogramming: ESL is investigating exactly this type of problem, and 
an entire prototype has been built and is being tested. 

Cells 13-19 - Libraries: NELS (NASA Electronic Library System) and RBSE (Repository- 
Based Software Engineering) are related projects that are building a reuse li- 
brary system that addresses many of the areas on this chart. 
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ASSETS NOTES 


Tool 1: Eli/InQuisiX 

Cells 6-16, E-G - The InQuisiX system supports the reuse of many types of compo- 
nents including: designs, code, documentation and test procedures. 


Tool 2: HyLite 


Cells 6-14, F-G - Developing versatile system that can be used to manage and reuse 
these types of assets. 


Tool 3: SEAL 

Cells 6G,H,J -16G,H,J - The SEAL has adopted an “expansive” view of reuse, where 
all products of the life cycle may be reused and composed of reusable products. 
Assets will be developed following pertinent software, hardware, communica- 
tions, and user interface standards. Documentation will follow the NASA Soft- 
ware Documentation Standard. All assets will be made widely available via 
asset repositories. 

Cells 19G,J - A guidebook for developing reusable Ada components and systems will 
be developed by the SEAL. This is a deliverable under a task being conducted 
by the SEAL for the Code QE Software Engineering Program. 

Cells 21G,J - A guidebook for transferring reusable Ada software in NASA will be 
developed by the SEAL. This is a deliverable under a task being conducted by 
the SEAL for the Code QE Software Engineering Program. 

Cells ‘23G- J - Tailorable software engineering process guidebooks are being developed 
for the various SEAL software domains. These guidebooks will incorporate 
standard, existing methodologies and tools as much as possible. Future training 
for SEAL and other LaRC personnel will be tailored to these guidebooks. These 
guidebooks are deliverables under a task being conducted by the SEAL for the 
Code QE Software Engineering Program. 

Additionally, an annual SEAL report is planned that will assess the scope, 
development processes, and transfer mechanisms for reuse of software products 
for NASA Ada projects. 
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Tool 4: RBSE 


Cell 6J - AdaNET (see Technology 13G). 

Cell 8J - AdaNET (see Technology 13G). 

Cell 10J - AdaNET (see Technology 13G). 

Cell 12J - AdaNET (see Technology 13G). 

Cell 14J - AdaNET (see Technology 13G). 

Cell 16J - AdaNET (see Technology 13G). 

Tool 51: LEARN-92 

Cell 10 - The focus in this effort is on code components, but the classification 
mechanisms being implemented in LEARN-92 could work for o ther f orms of 
assets as well. The emphasis is due to a current need within GSFC/Code 520, 
where there is a growing collection of reusable C++ components being circulated 
among developers, and a need to organize the components in a form that makes 
it easy to locate reusable code. 


Tool 52: KAPTUR 

Cell 21 - KAPTUR provides a mechanism for the rationales for various engineering 
decisions to be recorded. These can include after-the-fact lessons learned from 
the particular decisions made. 


Tool 53: KBSEE 


Cell 6 - The KBSEE effort has focused to date on the storage of generic requirements 
specifications and the automated configuration of requirements specifications 
for new systems based on the generic versions. The methodology encompasses 
other life-cycle products as well. 
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3. Proposed Actions 


During the wrap-up session, the workshop participants discussed ways to leverage 
their individual software reuse activities into a coordinated program to address NASA’s 
software development needs and to promote software reuse as an integral part of the 
NASA software development process. The participants concluded that these objec- 
tives can be accomplished by coordinating their software reuse activities and mar- 
keting their activities to NASA Headquarters as a coordinated, focused program to 
advance software reuse throughout the NASA community. The following preliminary 
action items were agreed upon: 

• Use this workshop document as the basis for a proposal to potential sponsors. 

• Form a Software Engineering and Reuse Team focusing on NASA problems. 
This team is to be led by either LaRC or ARC. Team members are to in- 
clude ARC, LaRC, LeRC, GSFC, JSC, JPL, MSFC, HQ, Rome Laboratory 
(Air Force), COSMIC, DARPA (ASSET), RBSE. This team should combine 

with SATWG/ 

SAAP Software Engineering Subpanel, chaired by E. Fridge of JSC. 

• Determine customer needs for the near term. This will be accomplished by 
looking at existing advocacy packages, by presenting current software reuse 
activities to HQ, and by soliciting feedback from HQ. 

• Use Code R Block Grants as a mechanism to influence software reuse in univer- 
sity curricula. Candidates are University of IUinois/Urbana-Champaign, Stan- 
ford University, University of Maryland, and Harvey Mudd College. 
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Software Reuse issues 


Defining software reuse 
What are NASA's Requirements? 
What will be the benefits? 

What needs to be done? 

Can we quantify our results? 
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What are the obstacles to software reuse? 

People are resistant - why? 

Tools and techniques to: 

Develop reusable software 
Identifying potentially reusable software 
Storing and retreiving reusable software 
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CT/fs^ WHAT IS KAPTUR? 

INCORPORATED 


KAPTUR to a tool designed to be part of a reuse-baaed software development 
environment. 

KAPTUR ha gone through two phases of prototyping: 

— KAPTUR *88 
— KAPTUR *88 

. Efforts are underway to bring the tool from a laboratory environment to software 
developers. 
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KAPTUR GOALS AND OBJECTIVES 

INCORPORATED 

SUPPORT REUSE QE SQFTWARE ASSETS 

• Capture anginaaring daclsions/ratlonalaa that want into thair davalopmant 

PROVIDE AN EASY TO USE ENVIRONMENT FOR ACCESSING CAPTURED 
KNOWLEDGE 

APPLY THE ENVIRONMENT TO SUP PORT SOFTWARE REUSE I N SMEX MISSIONS 




RATIONALE / BENEFITS 


INCORPORATED 


COST SAVINGS THROUGH INCREASED SOFTWARE REUSE 


RETENTION OF SOFTWARE ENGINEER KNOWLEDG E AHP EXPERIENCE IN A 
DATABASE ACCESSIBLE TO OTHERS 


IMPROVEMENT OF DEVELOPMENT PROCESS BY BUIL DING ON PAST 
EXPERIENCE AND LESSONS LEARNED 


CTA— HOW DOFS KAPTUR ASSIST IN REUSE? 

INCORPORATED 


. KAPTUR handles more than code components. 

— requirements 

— design 

— test (planned! 

• KAPTUR keeps a representation of components and kflOfflctltC that would assist 
in determining which particular components to reuse. 

• Components themselves aren't kept in KAPTUR. 

• KAPTUR provides information on where the components are kept (not 
implemented). 
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WHAT FORM DO COMPONENT 
REPRESENTATION AND KNOWLEDGE TAKE? 



* Mttlu pk Views 


• Decisions 

• Tradeoffs 


o Rationales 

- Entity Relationship Diagram 

- Classification Diagram 


KAI'IUR not only stores representations of systems, but also stores key 
development decisions and the rcastms behind the decisions. 
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KEY CONCEPTS IN KAPTUR 


ASSET 

Any software product that can ba rausad In future davalopmants 

• Indudaa a ya tares, aubsystams, objects, functions 

AHCHITECTUHE 

A description of tha structure of a software asset 
Uses one or more graphical views 

GENERIC AR CHITECTURE 

• An architecture that can ba instantiated or tailored to meat varying requirements 
INSTINCTIVE FEATURE 

• Any significant way in which an architecture differs from its alternatives 
The way in which an asset manifests a significant engineering decision 
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KEY CONCEPTS IN KAPTUR (continued) 

INCtmfOUATF.D 

TPRNATIVES MAP 

. A hierarchical description ol alternative architectures for a given type of aaaet 
nPUAIH MODEL 

• The legacy of knowledge about an application domain 
. Packaged lor easy access and reuse 

SUPPLY SIDE 

• The creatlon/mainienance of the domain model 

. Incorporation of new assets as they are developed, with features and rationales 
pFMAND SIDE 

. Access to the domain model for the purpose of reusing the assets It contains 


KAPTUR ENVIRONMENT DETAILS 

miwrtiRATMi 

WHITTEH IN C 

. Approximately 45% of code la automatically generated 



pSEfi TAP* VERSION 5 

CURREHTLV RU NS ON A SUN SPARCSIAHQM 
. Should run on any UNIX system supporting TAE 
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SOFTWARE ENGINEERING 



PLANNING and MANAGEMENT DEVELOPMENT 

Software Management Environment (SME) Knowlodgc-Bosod Software Engineering 

Environment (KBSEE) 


The Software Engineering work addresses a full spectrum of activities needed to: 

1 . plan, manage, and monitor the development of, and 

2. provide for the efficient and effective implementation of 
complex operational systems. 


Baste 

Knowledge-Based Software Engineering Environment 
(KBSEE) 


• Incorporates the Evolutionary Domain Life-Cycle (EDLC) Model 


P. 55 


GOALS OF THE RESEARCH: 

IN RESPONSE TO NASA SOFTWARE ENGINEERING INITIATIVE 


Sustaining Engineering 

• family of software systems 
. evolution of domain models 


Software Reuse 

• reusable domain specification 

• reusable domain architecture 

• reusable code 



Enabling Technologies 

- software process modeling 

• object oriented methods « tools 
. knowledge* based tools 

• object management 


EVOLUTIONARY DOMAIN LIFE CYCLE 


A'tttcrto* DmiK Ttrftl System 

UfmUM R*qulr*mt*u 



Terft* 

Sytum 


• Makes no distinction between development and maintenance 

• System viewed as evolving through several iterations 

• Life*cycle for family of systems 
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EDLC PROOF-OF-CONCEPT EXPERIMENT (EPOC) 

GOALS 


Demonstrate viability of Evolutionary Domain Life Cycle Approach 

Create demonstration version of Knowledge Based Software Engineering Environment supporting 
EDLC 

Domain Modeling 

Address Domain Analysis and Specification 
Target System Generation 

Address Knowledge Based Requirements Elicitation 



EDLC PROOF-OF-CONCEPT EXPERIMENT (EPOC) 
FEATURES 


Tool Support for Developing Domain Specification 

Provide support for Domain Analysis and Specification Method 
Create multiple view graphical representation 
Store Domain Specification 

Map multiple views to common underlying representation 
Store in object repository 
Multiple View Consistency Checking 

Determine whether Domain Specification rules obeyed 
Generate Target System Specification 

Tailored version of Domain Specification 
Knowledge Based Requirements Elicitation 


EDLC PROOF-OF-CONCEPT EXPERIMENT (EPOC) 
APPROACH 


Off-the-shelf CASE tools where appropriate 
Software Through Pictures (StP) 

Provides graphical front end 
Open systems architecture 
Object Oriented Programming Language Support 
Eiffel Language 

Compiler and component library 
Persistent object store 

investigate NASA developed tools where appropriate 
TAE User Interface Management System 
CUPS knowledge based system shell 
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Introduction 


• Presenters 

- Support Contractors, not Civil Servants 

• MITRE supports STB In Software Technology Infusion 

• Applied Expertise acts as HQ's liaison for Repository Based Software 
Engineering (RBSE) System 

- Representing JSC's Software Technology Branch 

• Its projects and activities 

• Its viewpoints 

• Point s-of-contact, NASA JSC/PT4 Houston, TX 77058 

- Ernie Fridge, (713) 483-8109 

- Dr. Charles Pitman, (713) 483-2469 

• Intent is to provide a broad-brush overview of our reuse activities vs. detailing 
the projects' technical or other merits to 

• Stimulate discussions 

- Foster information exchange 

_ _ _ — — Software Technology Brunch 
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Agenda 


• Themes 

• Projects 

• Observations, etc. 
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Themes 


• As many different meanings for REUSE, as there are reuse-related projects 

- There Is no specific group dedicated solely to reuse, but projects are 
(e.g., RBSE) 

- Each project has specific goals 

• Describing the projects will define how they support reuse 

• There are economic and other benefits to reuse 

• Reuse is a goal, it will be worked on and improved over time 

• Reuse can be facilitated 

• Transition from opportunistic to systematic reuse posture is underway 
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Re-Engineering Application (REAP) 
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JSC/PT4 


'SffiTBamos, 

MITRE 


tuneng tourc* 

ISO-Internal 


pupt *^**“ EM# maintwtanoe burden and provide iwngmnrttg for JSC legacy systems 

. Hugo Invaatmant In dllllcult-to-mslntaln, yet functionally raaponalwa programs 
. Redevelopment and translation, not economically feasible or otherwise practical 
. uvkafpfaoa haa Idatorlealty focused on IMS 

Prgvida daalgn recovwy sod reengineering copMrilltle. for raJmp^otlng legacy >«“> "»« 

main tal neb*#, modem, and batter systems 

Provide Methods, Standards, Toole, and Data integration lo facilitate the re-tonplementetton 
Focus on and leverage off COTS/GOTS tools, deviating only to provide otherwise unavailable capabilities 
implement an extensible, open system baaed on standards and erwlronments/tramswocha 


1 tools under common presentation control for 


Deliverables 

• -ss-SKSSKSW^^ 


. Design recovery lor FORTRAN delivered JAIfW; tor C by end of CY 92 
. Integration standards end framework investigation NOW 2 
. integrated REAP In JUM 93 

. faipoort for meMIma Informa tion capture, other languages 
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REAP 


Re-Engineering Application (REAP) 

■ Program design, La, cad graphs, argument usIT 


Reuse Aspects 


Toole and Toot 


Capture Ml code and as much as possible of other information (software Ufa cycle products) m 
electronic form m a repository 

Use analysis with human expert In the loops to abstract, group, and structure the 

i to obtain 


Variety of usually non-eiandard Inputs due to platform, language and other environmental 


Terminological differences and the lack of standard definitions for and understanding of 

the process and products of software development 


Ift ffe —swr^iwainianancs and design recovery aupport la avallablsi 
feoovery of highest level design Information from code la difficult end requires analysis 

. Oomeln knowledge often no longer available 

- Attaining moat abstract Information needs to be traded on against utility end HOi of effort 
r-u«romer/Werket driven iervor — 
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totartaca, nwtti rnn flail 


Library 


f buMt m Appacatton fl pacification by Nbcba an a ppropriate aacutfu, 
appNeaMon Martac*. and math modal* from among tha rautaUa software componants In Hbrwy 

AppNoatton apses MsnMy componants to ba Msgratod and relatlonsNps to aach other and almutstion 
EjhmuOw* hHnn components control Ms MM ol a simulation application and coordinaU Ns execution 
Applic a t i o n Ml oa m pa n e ntB SrtdQa math models and oxecuttva, and astabWah domain archtlocture 


AM Software Components mum conform to Intarlaos and comm standards 
loaaauraanagraDon 

• To anoourep* d evelop m ent olmodulailiallon,reu*aMWy, and ob|*ctorlsntodne** 

AM Software Components Include attributes lor component dasaiflcatlon, data Interface (unit*, 

■ inWaMiatlon requirements. ctcA and control dect^ 


i a mafor, fundamental development 


Consonant DMgn 
Functional 
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profsa Asms 

Mission 


Mission 


dsvstop* 

oomnaof 

funang scores 

JSOPT4 

UHCL 

HQ/Coda R 


PWPOMQOM 

. predictably and reUabty oompoaa models of minion and safety critical (MASC) applications and systama 
. Tranatonn meM Into raal world ayatama preserving the MASC properties 

• Rapraaant the pro -mss*. products, and Intertecee uaad to avolva and sustain the modal* aa Interrelated, 
traeeabl#, and reusable artifacts spanning the computer and software engineering Ule cycle 

Support both prods* and formal levels of modeling discipline 


Deliverables 

. Clear Lake life Cycle Model (CL-LCM) 

• Object Management System (QMS) 

• library Ma n age m e nt System (LM8) 

Schedule 

. fmflfl ||f) prototype delivered FY91 — continuous Improvement planned through FV9S 
. Ufa Cycle Methodology, delivery In FYW— continuous Improvement planned through FY96 
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•must • C o mpu t e md u ft iw w pine— — tftnorltli 
• Computer and software produds/modets 


Software Technology Branch 


Mission 


Reuse Aspects 


Ubtarlaa of S»e above, Including apedfle views and conflgurallons 


Kvolutlon wN always baght by updating lha modal and than proceed to update the existing, system so 
that Ita structure and behavior continue to minor the MASC p rop erties of Ms rigorous modal 

Significantly eatsnd tawSBonal enMty-aftrfbuls / re WdonsIrip-ettributs repre s en tati ons of semantic models 

Provide hierarchy of structures and diadpilnee tor evolving and sustaining traceable sets of semantic 
mo data: abebaetMspecs, virtual Meets, stable framaworfcs of subsystems, and stable Meets 


Bahavtor and structure ta support a rigorous dtootpdne of composing models to tractably subject 
MASC subsets of the precise models to formal methods 


Format modsta and meth o d s have not bean tractable far large, oomptssdMtrtbutad ayatama whh MASC 
functions and co mp o n ents. 

Appropriate objsct-bsasd dtodpNnaa odor the beat hops for controlling the We cycle complexities of 
MASC appScaMona and ayatama. Object-baaed dlsclpilnos are Insufficient: Freda# fine-grained models 
should provide extensible ssnwntios for struetur* and behavior Mamai to objects and systams of objects 

OMBltMS la natdtd to support such 
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contractor 

tundngsourct 

Rapository-Basad Software Enginaaring (RBSE) 

JSC/PT4 

UHCL, at al. 

HQ/Code C 


• Distribute technology across many industries and domains Deliver and support robust product set 

• Commit to customer-driven quality. Consistently monitor and Increase custom* benefits 

- Serve high leve r age, hlgMmpnct dvllten market* (Le., aerospace, education, and mission- and safety 
critical) affecting OS. eompetltNeneaa and from which technology spreads quickly 

• Introduce roust Into customers' mainstream software development practices so as to have them parallel 
the clarity, consistency end predictability of other engineering disciplines 

- Make reuse tools, assets, tnd practices more easlly/economlcaliy accessible. Apply human factors 
engineering, explore classification schemes, develop generalized Ufe-cycte process modal, and help lead 
cooperative efforts 

• Replace outdated architecture limiting system responsiveness and capability with opsn-systsms-bsssd 

library management system 

tIHUS 

• DaHvarabtes 

• Operational prototype 

• Highly capable service organization, ski ll ed In cataloging, managing, and delivering software assets 
(AdeNET Haip Date: (800) 400-1458] 

• Sator, higher quality products for NASA 

• Schedule 

. PubNo-domaln sottwera hum library (AdeNET) m operation since i960 

• Enhanced lunctlonaUty/perlomiance capability In SEP92 (Ia, NASA Electronic Library Sytiom (NELS)) 
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Rapository-Basad Software Enginaaring (RBSE) Reuse Aspects 


waaies • Standard We cycle practices 

wanoara aiafaveonponana 
- Hauaa Hbrsrtes, ouatomtoad In technology and tervloe 

°P— • ripand haao nf rerary tuppMsra anit nmtTTrmrt r — in* - — r — — ***r 

• Share tdrenett a* attar rapoaltoriao 

• PM erWeal technology gapa through reaaarcti 

• Adapt to changing cuWomer requtramenta by integrating research reeulte and COTS/GOTS products 

mmm* Cooperation, essential 

• Breadth of RAO program, critical whae technology and practice of reuse matures 
- To enooutaps development ot modulertzaMon, reueebtUty. end object orton ted no— 

. software pracMee Hrh, eaaentlal e* ~ *~ — * Mta, * ri "" <UM * Eitecttve route 

of oommon element, la necessary to approach efficiency end predictability ot other disciplines 

• NASA ean make a rrwjoc contribution to tie eotutton-bodi as a aouroo and a reuser 

• Thera era many barriers to reuse; no one program can so/ee IMo problem (Le., cooperation) 
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• Reuse software within domain* 

. Permit a domain specialist (aerospace engineer) with minimum Ad* experience to define completed 
applications from reusable component* 

• Permit domain spooled*! to modify and create drivers (architectures) 

• Automatically generate high-level cod* from domain specialist's graphical specification 

• Decrease long-term software costs 

• PCS— catalogs of libraries of parts and knowledge base to help link parts together 

• ESL— graphical logic editor for specifying connection of reusable components 


Deliverables 

- On schedule 

- Working prototypes of both PCS end ESL 
Schedule 

- Prototype* delivered end WFY« 

. Proot-of-oonoept testing of typical engineering applications due end ot FY92 

- Enhan c ements based on feedback In FY93 
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Parts Composition System / Engr. Script Language Reuse Aspects 


ikiui * flpuMfeta, doroto-€p»c*flc software pwH <prtmiUv mocM— ♦ drivn/qrapha) 

* Cattog* ol parts 

• Ubrartes 

opwafeA • Developer retrieves graph tram Ubrary. Invokes editor, end modiflea graph producing now driver with 
ddlarsnt architecture andtor modules 

• Graph translated to high-level language such aa Ada 

• Metadata about application and required Input, passed to knowledge baas to conllguralUl 

• user eatacts appropriate input sate, composes compute data package. Application ready tar asscutton 

oommttt 

• Moduteamuat adhere to standards to b*mdudad In Ubrary 

■ndng* . Not ad modules are reusable without adaptation 

• Modules should contain standard types of metadata for parsing and Inclusion into the knowledge base 
for the application developer 
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AN INPUT DATA PACKAGE 


tmiN 

• STS32-A0NTE CARLO ANALVSI5/0FP2A CVCLE - - 

• SVIIBOL TABLE BOOS 


ISVABOL 

•A00,P SO.SVNBOL 

•A00,P 0A3*TCLDEU . 6H0S I A/SVABOL 

• BEBIN CASE ANO PHASE DEFINITION 

i ••••••••••••••••••••••••••••••*••••• 

SCASE(O) /AENOEZUOUS PROFILE/ 

9 ••••••••••••••••••••••••*••••••••••* 

IPNASEOO) /NCI - EXECUTE OAS-2/ 


9 

9 


SOATA 


SinULATION DEFINITION 


DICTOA - 1 

NOABT - I 

I AANUU • 1 

HU -2 

KOVH • 5 

BOATE - 1909., 12., IB. 

UECTIA - 23., 54., 32.140 


•TUO UEH . S I AULATED 
•ORBITAL SINULATION 
•LIFTOFF DATE 
•START OF SIR (AECO) 


AONTE CARLO INITIALIZATION 


SOATA 

NTCP • 2 

HOISP - I 

•ADO, P 0A5*TCLDEU .AC- INITI AL/STSB-O 


•TUO UEHICLE AONTE CARLO 
•NAU OFF FOR REFERENCE 
• INI T COU - REF INTO ACT 
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Space Carter 
iy«M D wcmw 
T eUeotagy D«v«k 


INTUTT 


putpaMOOM 


INTelligont Ustr Interface (IUI) Development Tool 



comiMof 

JSC/PT4 

Infarancd, 

Barrios 


tunang tourca 

HQ/SSFP & 
NSTS 


. Reduce the complexity el apace flight simulation and Its heavy Input data construction and management load 

• Emphasis la on aiding us* In composing complete Input dele packages from available data groups, with 

minimal modtltcattona 

• Provide a uaer friendly graphical Interlace dial presents Informetion more efrectlvety and makes interactions 
dearer and more eWdant 

• Supply an Intelligent assistant (expert system) to check uaer Input lor consistency with s goal of making a 
program execute correctly on the first run 

• Supply a rats Posed reasoning system to aid In searching for data sets 

• Provide a generic tool configurable to any application 


OeUverablso 

. Knowledge base extended to cover additional application domains 

. proot-ol^onoept demonstration of programs running conecdy on their (fret run 


ProoS-ot-conospl aucooastuNy demonstrated In I 
Apply INTUIT to various eompilealod engineering application m CVS2 
, methodology for configuring knowledge bases In CY92 
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pnjsananw 

MTeNigent User interface (IUI) Development Tool Reuse Aspects 


l 

e a 

fi 

ft 

fi 

°P MMDn • User Invoh m a eonflgured INTUIT etisM 

• Selects an existing Input data package dose to his/tar needs 

• Selects (end modifies, W required) a tew new data groups to replace some o< the old 

• A complet dm package Is translated into exact tormat required by the computer, so that no changes 

•ft rioulnd In ttn •sitting Input structure — 

• INTUIT la meat uaatul whan: 

- inpul structure la compUeated, requiring both graphical user Interlace and expert system assistance 
• Input afructure must be readUy isconflgurable 

tMngi . INTUIT shad permits quick and sssy bulking ef IUIs and, therefore, efficient upgrade o( coinptsx 
skmftetinn programs Improvements In runstreem setup c* 90-40% (labor) 

• Ms, by making date use and reuse sealer anti more efficient 
- Reduce time required for user training 

— ■ Software Technology Branch 
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Observations, etc. 


• Barriers to reuse, both real and proceduraily ingrained, need to be 
eliminated 

- Standards 

• Paradigms 

• Culture 

• Incentives need to be developed and put in place 

• For reusing products developed elsewhere 

- For developing reusable products 

• Infrastructure must be developed, distributed, and made easily usable and 
available to foster high levels of reuse of products of the software life cycle 

. Software Engineering Environments 

• Repositories/Ubra lies— for accessibility 

• Reuse does not come free of charge, i.e., it costs to design and develop 

- Reusable items 

• Methods to make reusable components available and, then, to find, 
access, and utilize them 

— — — Software Technology Branch 

CLFjwg 
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Observations, etc. (Con'c.) 


• How to design for reuse is not a given, but a developing concept 

• Optimum granularity of reuse and reusable components, if it exists 
- Domain independence or dependence, or both 

• Probably the biggest payback lies with reuse at the process, design, and 
model levels, i.e., levels more abstract than code 

• Reuse is certainly not the proverbial silver bullet 


Software Technology Branch 
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NASA NapoattoryBaaed Software Englnaarlng Program 


NASA's Raposltory-Basad Software Engineering (RBSE) Program 
and Collaboratlva Efforts 


NASA Softwars Rsuss Tools Workshop 
May 4-5, 1992 


Dave Dike! 

Apptlad Expertise, Inc. 

1925 North Lynn Street, Suita 802 
Arlington, VA 22209 
70i 518-0911 
FAX: 516*0911 
ddikal@ajpo.aal.cmu.adu 
NASAMAIL: DOWEL 
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NASA Repository Baaed Software Englnaarlng Program 


Background - Management Structure 


Level 1 


Laval 2 


Laval 3 


Steering 

Committee 


NAS 

Ot flea of Comm 
Technology Tn 

K HQ | 

BfCiai Programa 1 
inatar Division | 



NASA JSC | 

information System 1 

Directorate | 
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lea Com puflng and 1 
hnktaas | 
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Scientist 


I Raaaarch | 

Product | 

Library I 


Development | 

Opera) Iona | 
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NA8A RtfK»llory-0iMd Softwiit Engineering Program 


Background - History 

• RBSE has oparatad a prototype public-domain softwara 
reusa library (AdaNET) alnca 1989 

• Outdatad architecture limits systam rasponsivanass and 
capability 

• Howavar, AdaNET Is now a highly capabla sarvlca 
organization, sklllad In cataloging, managing and delivering 
software assets 


.. Call the AdaNET help desk - 800 444-1458 
for mors Information 


NASA C<otw*< A *aamM MX • 14 Bufaoorsrw* No *01 
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— NASA Repoeltory-IUeed Software Engineering Program 

Concept in Brief 

• Software practice lacks essential elements common to 
mature engineering fields 

• No one program can solve this problem - Cooperation is 

essential 

• NASA can make a major contribution to the solution - both 
as source and reuser 

• RBSE Is committed to customer-driven quality 

• RBSE will serve hlgh-leverage, niche markets 

• Research will make reuse more accessible 


NASA Cooper Wre A^eamenl WCC f 14 Sutoxrtrad Mo. 101 


NASA BepotHory Bwd Softwar* Engineering Frog ram 


Software practice lacks essential elements.. 

... common to mature engineering flalda, for axampla: 
Standard practicaa 

m R*n1v would a build at think about adding $ now *ub~ba**m*nt to on 

. . ' . l jtJa i. uuiijy ka uarv ma#kr arvf MMUiM 



fwfc# «6our «fc/ny for equivalent changes. Baa id**, they argue, ft is 
afmpfa me tlar of progra mming. M [G. Booch, Object Oriented Daalgn] 

"... shipping tha product and getting tha detail* right later [Busina aa Weak) 

Standard components 

"... ft la highly unusual for a conatruction firm to bu/td an on-aka steal mitt to 
forge custom girder a for a new building... [G. Booch, Object Oriented 
Design] 


This Is a big problem 


NASA Cooper tf*ve Ayeamsnt MX * t« Suboorfrid No t 
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NASA Rtpoettory-BftMd Software Engineering Program 


Cooperation is Essential 

Without affactlva rausa of common elements, software 
engineering cannot approach tha afficlancy and 
predictability of other anglnaarlng disciplines 

• Thera are many barriers to rausa; no on* program can 
aohf a this problam 

. Breadth of R&D programs, balanced with cooperation. Is 
critical while tha technology and practice of rausa matures 

• Technology must gat into tha hands of users across many 
Industries and domains - Rausa libraries customize 
technology and services to needs of their customers 

• Share advances of other repositories 

Expand base of library suppliers and customers 
through Interoperability 


NASA Cmamak* ******* NCC %■ l« lobcorerwi No 101 
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NASA Rtpo«Nory-BM«d Software Enginaaring Program 


NASA can make a major contribution... 

Through RBSE, NASA Is working to Impact mainstream 
adoption of reuse, both as source and reuser of 
high-quality software assets 

• Replace outdated architecture with high-performance 
hardware and open-systems-based library 
management system 

• Deliver and support robust set of products 

• Fill critical technology gaps through research 

• Adapt to changing customer requirements by 
Integrating research results ana off-the-shelf products 

• Broaden customer and supplier base by supporting 
Interoperability 


NASACooparslirt A^wmrt NCC • -II Subcortracl No <01 P*f7 


NASA Rapoattory-Baaod Software Enginooring Program 


NASA can maka a major contribution... 

Objectives 


< Build loyal customer base among hlgh-Impact nlcha markats 
- customers whoaa auccaaa affects ll.S. competitiveness 
snd from whom technology success spreads quickly 

• Introduce reuse Into customers' mainstream software 
development practices so that their software engineering 
efforts parallel the clarity, consistency and predictability of 
other engineering disciplines 

• Make reuse tools, assets and practices easily and 
economically accessible to universities 

• Consistently monitor and Increase customer benefits 


NASA Cooper Mb a A^sstwN NCC t tt Sutoortfract No. 101 Pagol 
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.... NASA WopooKory B p— d SofTw Eng In— ring Program 

NASA can maka a ma^or contribution... 

Benefits 

• Incrsasad customer compstltlvsnass 

• Wtdaspraad dissemination of NASA-davalopad softwara 
assats and technology 

• Graduates who are better able to engineer large, complex 
software systems 

. Safer, higher quality products for NASA 


HASA &»*«#** 
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— NASA flop— HoryBo— d Software Engineering Program 

Commitment to Customer-Driven Quality 


Ensures that RBSE - 

• Provides customers with what they expect and need 

• Focuses on efficiency, l.s., providing products and 
services at a minimum cost while ever more effectively 
Increasing bottom-line benefits to target customers 

• Measures He impact using well-defined criteria 


NASACoefwMbe A*«m— NCC >1* Buboaii mi Ho. 101 
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NASA Repository- B aaed Softwars Engineering Program 


RBSE will serve high-leverage, niche markets 

• NASA/cIvlllan aaroapaca application domalna 

• Civilian mlaalon- and aoftwara-lntanslva, aafaty-crltlcal 
aystama 

• Educational inatltutlona Intaraatad In rauaa 
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• — — - NASA Repository- Baaed Software Engineering Program 

Research will make reuse more accessible by... 

• Applying human-factors engineering 

• Exploring new classification schemes 

• Developing a generalized Iffe-cycie process model 

• Helping to lead key cooperative reuse efforts 
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Software Reuse in 
Systems Architecture Branch 
Information Systems Division 
NASA Langley 
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Langley rmmtcA Ccntflf /Sywtwns ArcMttc tun Bi wteft 


Kathryn Smith 



OUTLINE 



• Background 

• Eli/InQuisiX overview 

• Plans 
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ElillnQuisiX 

Background 



Eli (now InQuisiX) Software Synthesis System - SBIR 
Software Productivity Solutions, Inc., Melbourne, FL 

Phase I SBIR (Completed Sept 1987) 

• Defined reusable software synthesis methodology 

• NASA CR 178398 Knowledge-Based Reusable Software 
Synthesis System 

Phase II SBIR (July 1988- Sept 1991) 

Objectives: 

• Integrate advanced technologies to automate the 
development and use of reusable components 

• Make software reuse easy to perform 

Build 1, Prototype library system [Automated Reusable 
Components System (ARCS) - US Army CECOM], Jan 1989 
Build 1.5, Initial Eli library system, March 1989 




hU<ioniiAifOfttubc»yd Sp<ct Adrwn«<ratioo 
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Kathryn Smith 



EWInQuisiX 
Background 2 



Eli ( Build 3) April 1991 

Automated set of cooperating reuse tools 
window and menu based user interface 
runs under XI I on a Sun 4 

A V i* ' nr*. *«.’ n jo *4 ■ 

Library facilities to support classifying, storing and 
retrieving reusable components 

Design Synthesis Tool - Software Through Pictures 

Component Checkout Tool 

File Checkout Tool 

Ada Component Metrics Tool 

Phase III (commercialization) Winter 1992 
Possible candidate for STARS 
Support from SAIC 
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InQuisiX 

Software Synthesis System 



* B Searchers 

• System A Software 
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Agronomics and Specs Adminialraiion 


Langloy Research Contor /Systems ArcNtoctut* Branch 


P. 78 


Kathryn Smith 










EliilnQu isiX 

Software Synthesis System 


"\ 


Flexible: 

• User defined component classes and classifications 

• User tailorable and user extensible 
Supports many types of attributes 

• Faceted classifications 

• Text 

• Re 

• Keywords 



NASA 
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Hypermedia Library Technology 
(HyLite) 


Presentation to 

NASA Software Reuse Workshop 
May 5-6, 1992 


Joseph H. Jupin 
Edward W. Ng 


Jet Propulsion Laboratory 
Pasadena, California 


nwniiw 


HyLite 



Agenda 



• Introduction 

E.Ng 


• NASA's Need for Hylite 

E.Ng 


• Accomplishments 

E.Ng 


• ESC 

J. Jupin 


• Summary 

J. Jupin 
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Introduction 


• HyLite is a research & development activity to produce 
a versatile system as part of NASA technology thrusts in 
automation, information sciences & communications. 


• Useful as a versatile system or tool to facilitate the 
construction of electronic libraries for: 

- software components 

• hardware parts or design diagrams 

- scientific or engineering datasets or databases 

• bibliography organized by special taxonomy 

- configuration management information 

- etc... 

E*nmvvim ^ 


APPLICATIONS and SPIN-OFFS (5 YEAR HORIZON} 
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HylTfet 

•HyLite provides the potential to address a begad range of 
NASA problems in the 1990's, such as, 

• scientific data deluge 

- rapidly increasing complexity in software development 

- ever growing volumes and variety of documentation 

• HyLite evolved from a task formerly entitled the 
Encylopedia of Software Components (ESC) 

• ESC was motivated primarily by the need for software reuse 

•It was designed in anticipation of the "K by N by L" problem, 
that is, K kinds of computers, N applications, & L languages 

•This presentation will focus on the software/reuse relevance 
of HyLite IWWUVW 


Hylite Accomplishments 
(FY92 and Projected for FY93) 


• Prototype for beta testing on color Macintoshs 

• Graphical user interface (GUI) developed for inserting new components 
and property knowledge, for browsing and searching databases, and for 
retrieving software from selected networks 

• Contain library of math software and library of data structures and algorithms 

• Presently being adapted as a graphical front-end for national software 
exchange experiment 

• To be adapted as an intelligent front-end to NAIF, a library of software 
tools and datasets for space flight navigation system 

• Investigate collaborative arrangements with Ames and Langley on 
applications in aeronautics, materials, and structures areas 

• Connect to Netlib, a very popular online software library 

• Initiate SBIR contract for commercial spin-off 
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Encyclopedia of Software Components (ESC) 


Overview 


- Pertinence to Software Reuse 

- ESC Proof of Concept 

- ESC Prototype 

- Current Developoment Effort 

- Future Enhancements 

- System Walkthrough 

- Technology Components 

- Summary 


Pertinence to Software Reuse 


• Facilitate Electronic Search for Software 

• Transparently Link Software Repositories 

• Organize Software into Logical Units 


wmnawn 
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ESC Proof of Concept 


• Development Environment 

• SuperCard on Macintosh 

- Think C 

• Features 

- Browser 

- Publisher 

- History List 

• Lessons Learned 

> Stronger programming language needed 

• Better representation for software classification 

• Software classification needed 

- Automatic GUI generation needed 


mnwiif yi*i 


ESC Prototype 

Development Environment 

• Macintosh Allegro Common Lisp 
■ Think C 

- PixelPaint Professional 

- Canvas 2.0 

Features 

- Browser 

- Searcher 

- Publisher 

- Retrieval Mechanism 

- Classification Mechanism 

- Linnaeus 
-- Semantic Networks 


■WKMIVMI 
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Current ESC Development Effort 


• Port to Unix workstations running under the 
X window system 


• Inclusion of AI technologies 

- Intelligent retrieval 

- Learning from experience 

- User modeling 

- Incomplete retrieval statements 

- Spelling and grammar correction 

- Automatic suggestion of alternative retrieval 

requests when a trieval fails 


• Updating the Prototype 

- History List 

- Hypertext 


to include other capabilities 


Bwwnuyim 
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ESC System Walkthrough 


nwnywi 
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Technology Components 

• Object Oriented Databases 

• Classification Scheme based on Semantic Networks 

• Automatic GUI generation 


BWHWDVI*! J 
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Summary 


• HyLite represents an important area of NASA's computer 
science base research and development 

• It is promising in significant potential pay-offs to a broad 
range of NASA problems 

• Software resue is one important application 

• With mutual leveraging among NASA Centers to industry 
and universities, we can make significant progress in the 
next 3-5 years 

• JPL is strongly motivated to cooperate with other NASA 
Centers 

ntvama 
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COSMIC: Still Changing After All These Years 


L. Scott Clark 
Assistant Director 
COSMIC 

The University of Georgia 
382 East Broad Street 
Athens, GA 30602-4272 


scott@cosmicl .cosmic.uga.edu 
Voice: (706)542-3265 
Fax: (706) 542-4807 

®" NASA 

Software Reuse Tools Workshop (5/92) PAGE 


COSMIC: Sti ll Changing After All These Years 

COSMIC OVERVIEW 
Historical Background 

• 1958 Space Act 

• COSMIC Founded in 1966 

• Contracted out of Code CU at Headquarters 

• NMI2210 

NASA 

Software Rmn* Tooto Workshop (5/92) PAGI 
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COSMIC: Still Changing After All These Years 




COSMIC OVERVIEW 
COSMIC Now 

• Functional Divisions 

• Available Computing Resources 

• Inventory Composition 

• Characterization of Customers 

• Promotional Efforts 


NASA 
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COSMIC: Still Changing After All These Years 

COSMIC OVERVIEW 
COSMIC 

And The Software Innovator 

• Technology Utilization Offices 

• Software Submittal 

• Program Checkout And Evaluation 

• Tech Brief Awards 





Softwnrc Rcunc Tool* Workshop (5/92) 
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COSMIC: Still Changing After All These Years 


SUBMITTAL/DISTRIBUTION ISSUES 

Connectivity 

Software Submittals 

• Coordination Of Submittal With TUO 
Transmittal Documents 

• Documentation 

• Authorization /Security 

• COSMIC Author Communication 

• Research or Pilot Codes 

NASA 

Software Reuse Toole Workshop (5/92) PAGE 



COSMIC: Still Changing After All These Years 

SUBMITTAL / DISTRIBUTION ISSUES 
Software Distribution 

• NASA vs Outside Customers 

• Documentation 

• Ordering 

• Authorization/Security | 

• Intellectual Property Rights 

NASA 

PAGE 6 
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CERTIFICATION OF REUSABLE SOFTWARE 

COMPONENTS 


Presentation to: 

NASA Software Reuse Tools Workshop 


5-6 May 92 

Rome Laboratory 
GriffissAFB NY 13441 


Deborah Cerino/C3CB/DSN 587-2054 


Overview 


• What is Certification? 

• Certification Considerations 

• Test Techniques 

• Formal Verification 

• Quality Analyses 

• Research Areas 

• Rome Laboratory Program Plan 


Considerations For Certification Of Reusable Components 



certification Methodolo gy for Reusable Software Components 



Aff<y Tedu*j— •'Took IAW 



Domain Specific Reuse Library 


Why Certify Components? 
• insure high quality 


• provide degrees of confidence 

• aid in reuse decisions vs 

development from scratch 

• alleviate legal issues 

• promote reuse; significant cost 

savings (over 50%) 


What will this Program provide? 

• certification process-multi-level 

• advanced techniques/tools for component 

analyses (software test & verification, 
software quality assessment) 

• another dimension for choosing reusable 

components (e.g., choose a highly 
tested over a poorly tested component) 
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■STRAWMAN certification strategy 


LEVELS 


LEVEL 4 


LEVEL 3 


LEVEL 2 


LEVEL 1 



$ - COST TO PRODUCE & CERTIFY 
$ -COST OF PURCHASING COMPONENT 


CORRELATION BETWEEN BRANCH TESTING AND ERRORS FOUND 

NO OF CHECK SOURCE. 1 987 STUOY FROM JAPAN 
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Ada Test & Verification System (ATVS) 
Analyses Capabilities 


\ 



Inputs 



Outputs 


STATIC ANALYSES 



Reports 


LOOK AT CODE STRUCTURE 

What are al the variable, parameters, etc. names ? 
Where are they located in the code? 

Which units cal/are caled by other units? 

What does the unit nesting look Bte? 

How many LOC in each unit? 

How many tasks? 

How many procedures? 
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STATIC ANALYSES 


BENEFIT: Identify a Potential Problem 

• SET/USE REPORT 

• SOURCE COOE REPORT 

• PROGRAMMING STANDARDS REPORT 


18 OCT IBM 10:24 

Program Library : SIMULAT OR ;WORK 

atvs object set/use report 

PAGE 1 

Objact Nam* ^ 

Compilation Ur* 

OacL/SaMJaa 



05-SEP-1989 113021* 

* CAfliBOOY 





PROC.BOOY 

CAR 



CAR_DATA VARIABLE 

CAfliBOOY 

40 14S 16 

• C REATE _OAR_UST BOOY 


06-SEP-1W9 0735:11* 





aoo.car.to.ust 
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car ^formation in_parm CREATE_CAR_usraoov 

ANOMALY: Ob 
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* CREATE_CAR_ 


LI ST: BODY 


COMPILATION UNIT LEVEL METRICS * 
08-SEP- 1989 07:35:11 * 


Structure Units Declared 
Package 

- - Bodies - -- -- -- - 

Procedure 

- - Bodies - -- -- -- - 

- Generic Instantiations - - - - 

- Maximum Program Unit Nesting Depth 
With Context Clause ------ 

Use Context Clause ------ 

Source Lines -------- 

- Blank- --------- 

- Code Only - -- -- -- - 

- Comment Only ------- 

- Code Followed Comments - - - - 

Line) of Code -------- 

- 0 Semicolons ------- 

- 1 Semicolon- ------- 


1 

3 

4 
1 
1 
1 

95 

20 

70 
4 
1 

71 
36 
59 


170CT 1969 14:18 ATVS PROGRAMMING STANQAROS REPORT PAGE 1 

Program Library: SIMULATOR ^VORK 

Corrptetion Unit: CAR:BOOY 

Standards Version: 28-SEP-1969 07:46:48 


1 with TEXT JO. CREATE_CAR_UST; 

2 uaa TEXT IO, CREATE_CAR_UST ; 

(Sid F16 violated: USE dauae - forbidden construct present) 

3 procedure CAR is 

(Sid C01 violated: Percentage of source lines with comments -minimum of 60 not achieved. Percentage. 0) 

4 CAR DATA : CAR JNVENTORY_TYPE ; 

5 

6 begin 

7 

8 PUT fear inventory example*); 

9 NEW LINE; 

10 PUT(* Enter Wormalion tor 4 cars*); 

11 NEWJJNE; 

12 for I in 1 ..4 loop 

(Std F07 violated: Unnamed Loop - forbidden construct present) 

13 NEWJJNE; 


STATIC ANALYSES 


BENEFIT: Aid Maintenance of Software 

• ENTITY CROSS RffERENCE REPORT 

• UNIT STRUCTURE REPORT 
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ATVS UNIT STRUCTURE REPORT 


PAGE 1 


17 OCT 1989 1«:S9 

Prog r*m Library: SIMULATOR; WORK 

Structure Unit 


Unit Kind Starting Source Line 


• CREATE_CAR_L I ST : BODY 


08-SEP-1989 07:35:11 


CREATE_C AR_L I ST 
. ,CAR_TYPE_I0 
. .CAR COLOR TYPE_IO 
. .STYLE_TYPE_IO 
. .PRICE~TYPE_IO 
. .GET 

, . ADD_CAR_TO_L 1ST 
. ,PUT _ LIST 


Package Body 

3 

Generic Instantiation 

9 

Generic Instantiation 

9 

Generic Instantiation 

10 

Generic Instantiation 

11 

Procedure Body 

17 

Procedure Body 

50 

Procedure Body 

64 



ATVS 

Database 



Instrumentation 

Routines 



LOOK AT RUN TIME BEHAVIOR 


• Which sections ot code have 

been executed? 

• Hoar many times has each branch 

been executed? 

• How much time was spent in a 

particular section ot code? 

• What sequence of tasks was executed? 


ATVS 


Post Execution 
Analysis 



Reports 
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DYNAMIC ANALYSES 


BENEFIT: Provide Test Coverage 


• EXECUTION COVERAGE 

-UNTT COVERAGE REPORT 
•BRANCH COVERAGE REPORT 

• T1ANG REPORT 

. TASMNG REPORT 


UNIT COVERAGE REPORT 


Comp . Unit 

Structure Unit 

Line 


NUMB 

E A OF EXECUTIONS! 

| ( Normalised lo Maximum > | 

1 

Kind 

Count 

| 20 40 60 80 1001 

| , - — — — — , ** e • 1 

HOO FUNCTIONS: BOO Y 
HOD FUNCTIONS 

2 

PKG BDY 

0 

1 1 
1 1 

CALC LEAP YEAR 

4 

FUNC BDY 

3 


GETDATE 

16 

FUNC BDY 

2 

| I 

DATE KAN IP: BODY 
DATE MAN IP 

6 

PKG BDY 

0 

1 1 
1 1 

NEXT~DATE 

ft 

FUNC BDY 

3 

| 1 

DATE_LAB : BODY 
DATE_LAB 

_ A 

PROC BDY 

l 

1 1 

block 24 

24 

BLK STMT 

3 

blocOs 

43 

BLK STMT 

3 

1 1 


branch coverage report 


Structure 

Unit/ 

Line 


1 Invo- Total 
feet Iona Branches 
I 


Branches Percent I 
Executed Branches I 
Executed I 


Branches 

Not 

Executed 


COMPILATION UNIT: MOO_f UNCTIONS : BODY 


HOD FUNCTIONS / 2 
CALCLEAPYEAA / 4 
GET DATE ~ / 1% 


COMPILATION UNIT: DATE_MANIP : BOOT 


0 « I 

50 t I 23 

100% I 


DATE HAN IP / 6 0 

NEXt”0ATE / • 3 


0 % I 

20 » I 5 6 7 0 9 10 
11 12 13 14 15 16 


BRANCH COVERAGE REPORT 


• UOO.FUNCHON8AOOV 

2 p«^bodr MOO JUNCTIONS (0 

4 fcnoOoa GNjCJJMP_YEAR< Ta*J>nto : M OMo ) Mum bo t tom It 


“ Bnwh 1 PROGRAM UNR START 

I ( TnaUDafeVaar Mad 400 - 0 ) fMH 
M Brandi 0 * CONDITION TRUE 
felwii TiMi 

«M ( Ta^jbaMiYaar mod 4-0 ) and ( TaaUMfeVa m mod 100 A4 ) 


ATVS STATUS 


• Government Version Completed (Sep 89) 

• Commercial Version Currently Available - AdaQuest 

- Fully supported 

- Robust 

- POSIX/Motif Compatibility - Jul 92 

- Additional standards from 

A Ha Oualitv & Stvle_Gliidfi.- Jul 92 



MUTANT - A VARIATION OF THE ORIGINAL PROGRAM 

THAT CONTAINS A SINGLE INSERTION OR DEVIATION 
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MUTATION TESTING 


EXISTING MUTATION TESTING SYSTEM CAPABILITIES 

• ANALYZES FORTRAN CODE 

• AUTOMATES MUTATION TESTING PROCESS 

(GENERATES AND EXECUTES MUTANTS) 

- MAINTAINS DATABASE OF TESTING STATUS 

- LOCALIZES PROGRAM ERRORS 


USER RESPONSIBILITIES 

• GENERATE TEST CASES 

- VERIFY TESTCASE RESULTS 

- ESTABLISH TEST COMPLETION CRITERIA 

- IDENTIFY PROGRAM ERRORS 


MUTATION TESTING 


MUTANT OPERATORS • A SIMPLE TRANSFORMATION 


.STATEMENT ANALYSIS 

• REPLACE EACH STATEMENT BY ‘CONTINUE* 

• REPLACE EACH STATEMENT BY ‘RETURN’ 

- REPLACE THE TARGET LABEL N EACH "OCT STATEMENT 


. PREDICATE AND DOMAIN ANALYSIS 

- TAKE THE ABSOLUTE VALUE OF AN EXPRESSION 

- REPLACE ONE ARITHMETIC OPERATOR BY ANOTHER 

- REPLACE ONE RB-AT10NAL OPERATOR BY ANOTHER 

- REPLACE ONE LOGICAL OPERATOR BY ANOTHER 


. COINCIDENTA L CORRECTNESS 


- REPLACE A SCALAR VARIABLE 

- REPLACE AN ARRAY REFERENCE 
• REPLACE A CONSTANT 
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mutation testing 


MUTANT STATUS 


NUMBER OF MUTANTS GENERATED: 307 
PERCENT EXECUTED: 100% 

PERCENT KILLED 


ALL MUTANTS 


SAL 

PDA 

CCA 


CTL 

STM 

DMN 

PRO 

ARY 

CON 

DPM 

SCL 



99.02% 

100 . 00 % 

100 . 00 % 

98.90% 

95.24% 

100 . 00 % 

100 . 00 % 

100 . 00 % 

99.00% 


RL SOFTWARE QUALITY 
FRAMEWORK APPLICATION 




















QUALITY REPRESENTATION 


acquisition 

CONCERNS 



USER ORIENTED VIEW OF PROOUCT QUALITY 

REUSABILITY 



Ref: Specification Of Software Quality Altribotes (RADC-TR-S5-37) Vols l-IH 


Quality Evaluation System (QUES) 


• Goals 

• Achievements 


AdaPDL 

Ada/FORTRAN Sonree Code 
Data CoUectioa Fotom — 
S/W Problem Reports 
SLCSE Dolaboae Iafonnatim 



VAXSUttoW 


oQoaUty Growth 



o S/W Qoality Indicators 
(AFSCPSM-14) 


SUNWorkatadon • S/W Management Indicator* 

(APSCPWM3) 


o Automates The RADC S/W Quality Framework Evaluation Guidebook 
(RADC-TR -85-37, Volume 111) , 

o Supports Acquisition Managers, Project Managers, St Engineers 
o Allows Quality Goals To Be Specified 
o Assesses Software Product Quality 
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SOFTWARE QUALITY GOAL REPORT 


PROJECT: 

PHASE: REQUIREMENTS 

LEVEL: CSO 

ENTTTT NAME: AR1J) 

METRIC CALCULATION SATE: 10M8MS 


DATE: 1MM 



framework experience and 

RESULTS (JAPAN) 


AVERAGE 3% OF DEVELOPMENT COST PER FACTOR 


25 % SAVINGS THRU FULL-SCALE DEVELOPMENT 


51% SAVINGS AFTER 1 YEAR MAINTENANCE 
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DEFINITION: Collection of techniques that apply the formality 

and rigor of mathematics to the task of proving me 
consistency between an algorithmic solution and a 
rigorous, complete specification of the intent 
(behavior) of me solution 


Develop new techniques for Insertion into Certification Methodology 


• Software Fault Tolmnc* 

• V & V o< Artificial Intelligence components 

» P w1om ia no»« M «« «m <n l kyf»W4nwapp«cWk)nt 
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PROGRAM PLAN 


• Develop Initial Certification Framework 

• Funded by CIM central funds 

• Contractor * RTI 

• Schedule: May 92 - Dec 92 

• Deliverables - Technical Report 

• available tools/techniques 

- approaches for information storage 

- certification framework 

- plan for application of the certification process 

- plan for cost/benefit analysis 

- plan for incentives 

• Apply and Validate Certification Framework 

• Funded by RL 6.2 funds 

• Schedule Jul 93 * Jul 96 

• Deliverables -Technical Reports 

- Revised Certification Framework 

- Results of application of certification process 
Dmi life nf swvet/hArtafit analysis 


SUMMARY 

CERTIFICATI ON PROCESS & TOOLS 

PROVIDES MEASURE OF CONFIDENCE IN REUSABLE COMPONENT 

PROVIDES SCALE & PERFORMANCE DATA IF REQUIRED 
SOUND BASIS FOR BUILD/BUY DECISIONS 


Asset Source for Software 
Engineering Technology 
(ASSET) 


Oiarte* W. Ullie. PhD 
SAIC 

703-749 H732 

lillictSmcl.ipan^xividK.edu 

/n turn \ C'erfrorsfu** 

A a f m* I # . » *yv») ■ 


GOALS 


ESTABLISH A DISTRIBUTED SUPPORT SYSTEM FOR SOFTWARE 
REUSE 

SHORTTERM 

• IMPLEMENT A SOFTWARE REUSE LIBRARY 

• BECOME FOCAL POINT FOR SOFTWARE REUSE WITHIN THE DEFENSE 
INDUSTRY 

LONG TERM 

• HELP STIMULATE A US SOFTWARE REUSE INDUSTRY 


■ Se*0*Hr+ Apptr cm fr on s 
/hfmrr «iW Ck#7*arm*<* 


activities 


. ASSET ACQUISITION, CATEGORIZATION, AND DISTRIBUTION 

• ASSET CONFIGURATION MANAGEMENT (INCLUDING PEDIGREE 
MAINTENANCE) 

• ASSET RECALL 

. SETTING UP LOCAL REUSE PROGRAMS AND REPOSITORIES 

• "YFI ,! ,0W PAGES" FOR REUSE GOODS AND SERVICES 



Art Corry*Arty 


TECHNOLOGY INTERESTS 

DISTRIBUTED NETWORKING OF REPOSITORIES 
INTERCHANGE OF ASSETS AMONG REPOSITORIES 

• NO LOSS OF INFORMATION 

• DESPITE DIFFERING ORGANIZATION OF REPOSITORIES 

CONFIDENCE INDICATORS 

• DETAILED PEDIGREES OF ASSETS 

• CERTIFICATION TECHNIQUES 


"SEAMLESS" INTEGRATION WITH LOCAL ENVIRONMENTS 
AND REPOSITORIES 
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NTSC Reuse Initiative 


• Naval Training System Center 

. Adaptation of STARS Technology 

• Reuse Library Development 

• Flight Simulation Domain Analysis 

• Assist in Asset Moderization 

. Develop Reuse Software Assessment Tool 



ASSET Business Plan 


Market Analysis 

Assess current understanding of software reuse technologies, 
benefits, and requirements within the organizations surveyed, and 
their commitment to integrating software reuse into their software 
development process. 


Business Analysis 

Analyze business models to determine the best approach to manage a 
software reuse library. 

Business Plan 

Use business and market analyses to describe the transition from 
government funding to self-sustaining operations. 


ASSET LONG RANGE PLANNING 


INFRASTRUCTURE 

SHORTTERM 

MEDIUM TERM 

LONGTERM 

1992 

1993 - 1994 

>1995 

Implement prelim 
yellow pages 

Implement RIG 



yellow pages 


Install advance 



library mech. 



Experimental 

Interconnect 

Interoperability 

interconnection 

multi-library 


| (CARDS, AdaNET) 


Local Security 

Network Security 

Interoperability 



security 

Survey Existing 

Formulate 


legal Work 

basis for industry 


Survey electronic 
commerce 

Formulate 

basis 

Same* Applications 

An Empto)** Compwny 

ASSET LONG RANGE PLANNING 1 


PRODUCTS & SERVICES 

SHORTTERM 

MEDIUM TERM 

LONGTERM 

1992 

1993 - 1994 

>1995 

STARS CDRLs 

Program Specific 


STARS BB 

Products & Services 


STARS NO 
STARS Products 

Consulting Services 


Other 

Set up local libraries 



Cross domain components 1 


Standards & bindings 
Reuse technology tools 

Reuse Library 
Services 






ScmncmAootications 


An E m pto f * Omrnd Company 
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ASSET LONG RANGE PLANNING 
MARKET DEVELOPMENT 

SHORT TERM 
1992 

MEDIUM TERM 
1993 - 1994 

LONGTERM 

>1995 

Quantified market 
analysis & business 
plan 

Transition to fee 
for service 
operation 

Self-sufficient 

operation 


Marketing force 
separate balance 
sheet, P&L 

Customer base 

Identify & have pilot 
supply agreements 
(cotnmerical & gov't) 

Some industrial 
supply agreements 

Some gov't supply 
agreements 

Supplier base 



- 

Some* Applications 

tnfmmmhonMi nrrrunttM 


An&mph y — &m*d Company 



A** r « n y wr 
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Science Applications International Corporation 5 ■■ ~ = 

Re-Engineering With Reuse 

DEFINITION 

A process of software analysis and development that takes as input: 

• Software artifacts from a I.cgacv system. 

• Domain Knowledge (Vocabulary, Tuxonomics, Models, Standards) 

• Reuse Library 

• New Requirements (optional) 

For the purpose of producing as output: 

• Target System of higher quality, 

• Updated Domain Knowledge, 

• New Reusable Assets. Tar«et System 



New Domain Knowledge 


Domnin Knowledge / Re-Engineering 
— — K J (With Rense) 


New Assets 


Legacy System 


Reusable Assets 


Exiting Assets 


Library 



IMW-H — — M 
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Phased Inspections 


Single Inspection Pluse 


Rigorous 

Specific 

Quality 

Goal 


Rigorous 

Specific 

Quality 

Goal 

Single 

Inspection 

Phased 



Inspection Support Toolaet 


Managing 


Impacting 


Monitoring 


Same* Applications 
international Corporation 
An Emp to y**- Omtd Company 


NTSC Reuse Initiative 


Naval Training System Center 
Adaptation of STARS Technology 
Reuse Library Development 
Flight Simulation Domain Analysis 
Assist in Asset Moderization 
Develop Reuse Software Assessment Tool 
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iciencc Applications international Corporation -■■■■■- 

Re-Engineering With Reuse 

DEFINITION 

A process of software analysis and development that takes as input : 

• Software artifacts from a Legacy system. 

• Domain Knowledge (Vocabulary, Taxonomies, Models, Standards) 

• Reuse Library 

• New Requirements (optional) 

For the purpose of producing as output : 


• Target System of higher quality. 

• Updated Domain Knowledge, 

• New Reusable Assets. 


Target System 



tnct AppUnlUa* iMtnuOimal CVporattea 
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